Orale Parte 1 Ambienti di programmazione

Capitolo 1

L’architettura di un sistema

GNU/Linux

1.1 L’architettura del sistema.

Prima di addentrarci nei dettagli dell’amministrazione di un sistema GNU/Linux, conviene

fornire un quadro generale per introdurre i vari concetti su cui si fonda l’architettura di questo

sistema, che nasce da quella, consolidatasi in 30 anni di impiego, dei sistemi di tipo Unix.

Il fatto che questa architettura abbia una certa età fa sı̀ che spesso i detrattori di GNU/Linux

ne denuncino la presunta mancanza di innovatività, ma anche le case hanno da secoli le stesse

basi architetturali (porte, muri e tetti), ma non per questo non esiste innovazione. Il vantaggio

dell’architettura di Unix infatti è quello di aver fornito una solida base per la costruzione di

sistemi affidabili ed efficienti, consolidata e corretta in decenni di utilizzo, tanto che, per citare

Henry Spencer: “those don’t

who understand UNIX are doomed to reinvent it, poorly”.

1.1.1 L’architettura di base.

Contrariamente ad altri sistemi operativi, GNU/Linux nasce, come tutti gli Unix, come sistema

multitasking e multiutente. Questo significa che GNU/Linux ha un’architettura di sistema che

è stata pensata fin dall’inizio per l’uso contemporaneo da parte di più utenti. Questo comporta

conseguenze non del tutto intuitive nel caso in cui, come oggi accade sempre più spesso, esso

venga usato come stazione di lavoro da un utente singolo.

Il concetto base dell’architettura di ogni sistema Unix come GNU/Linux è quello di una

rigida separazione fra il (il nucleo del sistema), cui si demanda la gestione delle risorse

kernel

hardware (come la CPU, la memoria, le periferiche) ed i processi, (le unità di esecuzione dei

programmi), che nel caso vanno dai comandi base di sistema, agli applicativi, alle interfacce per

l’interazione con gli utenti.

Lo scopo del kernel infatti è solo quello di essere in grado di eseguire contemporaneamente

molti processi in maniera efficiente, garantendo una corretta distribuzione fra gli stessi della

memoria e del tempo di CPU, e quello di fornire le adeguate interfacce software per l’accesso

1

1. L’architettura di un sistema GNU/Linux 11

alle periferiche della macchina e le infrastrutture di base necessarie per costruire i servizi. Tutto

il resto, dall’autenticazione all’interfaccia utente, viene realizzato usando processi che eseguono

gli opportuni programmi.

Questo si traduce in una delle caratteristiche essenziali su cui si basa l’architettura dei sistemi

Unix: la distinzione fra il cosiddetto che è l’ambiente a disposizione degli utenti, in

user space,

cui vengono eseguiti i processi, e il che è l’ambiente in cui viene eseguito il kernel. I

kernel space,

due ambienti comunicano attraverso un insieme di interfacce ben definite e standardizzate;

secondo una struttura come quella mostrata in fig. 1.1.

Figura 1.1: Schema della struttura del sistema operativo GNU/Linux.

Questa architettura comporta che solo il kernel viene eseguito in modalità privilegiata, ed

è l’unico a poter accedere direttamente alle risorse dell’hardware. I normali programmi invece

vengono eseguiti in modalità protetta, in un ambiente virtuale, l’user in cui essi vedono

space,

se stessi come se avessero piena disponibilità della CPU e della memoria, ma in cui possono

accedere alle periferiche e alle altre funzionalità messe a disposizione del kernel solo attraverso

una serie di funzioni di sistema standardizzate, dette Lo standard in questo caso si

system call.

chiama POSIX.1; ma oltre a quelle dello standard Linux supporta ulteriori relative

system call,

a sue estensioni specifiche.

Le e tutta una serie di ulteriori funzioni di base sono tradizionalmente raccolte in

system call

un’unica libreria che pertanto diventa essenziale per il funzionamento di qualunque programma

(tratteremo le librerie, e come vengono gestite nel sistema, in sez. 3.1.2). Nel caso di Linux

questa libreria, illustrata nello schema in fig. 1.1, è la (chiamata in breve glibc),

GNU C library

che costituisce una delle parti fondamentali del sistema.

1. L’architettura di un sistema GNU/Linux 19

In sostanza quello che succede è che da un certo punto di vista l’unico “vero” programma che

viene eseguito è il kernel, che si incarica di costruire questo ambiente virtuale in cui far girare

gli altri programmi. Una parte del kernel, quella indicata in fig. 1.1 come è deputata

scheduler,

della gestione del tempo di processore, e provvederà a decidere volta per volta qual è il processo

che deve essere eseguito in un determinato momento (realizzando cos`ı il multitasking).

Una seconda parte, quella indicata in fig. 1.1 come (sigla che sta per ), si

VM Virtual Memory

occupa invece di gestire l’uso della memoria disponibile. La memoria virtuale è uno dei

sottosistemi più importanti del kernel, oggetto di continui miglioramenti in quanto critico per

tutte le prestazioni del sistema, perché è quella che fa in modo che ogni processo veda uno

1

spazio di indirizzi proprio che poi viene rimappato nella memoria fisica effettivamente presente,

cos`ı che sia impossibile che un processo possa accedere alla memoria di un altro processo. La

memoria virtuale si incarica anche di gestire, in caso di esaurimento della RAM, l’eventuale

spostamento delle pagine di memoria meno usate su uno opportuno spazio disco (lo che

swap,

tratteremo in sez. 5.1.7) evitando di fermare l’esecuzione di un processo per una temporanea

mancanza di memoria. Torneremo brevemente sull’argomento in sez. 1.3.2.

Infine c’è un’ultima parte del kernel, indicata in fig. 1.1 con l’indicazione generica anche

driver

se in realtà non è un unico sottosistema come le precedenti ma, come vedremo in sez. 5.2.5, un

insieme di “moduli” che consentono la gestione delle varie periferiche, fornendo un accesso alle

stesse per conto dei programmi. Questa parte, come vedremo meglio in sez. 1.2, permette di

definire una interfaccia di accesso generica per i dispositivi, cui spesso si fa riferimento dicendo

che in un sistema unix-like “tutto è un file”.

La conseguenza più importante di questa separazione fra e è che in

user space kernel space

questo modo non è possibile che un singolo programma possa disturbare l’azione di un altro

programma o del kernel stesso, e questo è il principale motivo della stabilità di un sistema Unix

nei confronti di altri sistemi in cui i processi non hanno di questi limiti, o vengono, per vari

motivi, eseguiti all’interno del kernel.

1.2.2 L’albero dei file ed il Filesystem Hierarchy Standard

Una delle caratteristiche peculiari di un sistema unix-like è che l’albero delle directory è unico;

non esistono cioè i vari dischi (o volumi) che si possono trovare in altri sistemi, come su Windo-

24

ws, sul MacOS o sul VMS. All’avvio il kernel monta quella che si chiama la directory radice (o

) dell’albero, che viene indicata con “ ”, tutti i restanti dischi, il CDROM e qua-

root directory /

lunque altro dispositivo contenente file, verranno poi montati (vedi sez. 5.1.3) successivamente

in opportune sotto-directory della radice.

Come per il processo iniziale , che non è figlio di nessun altro processo e viene lanciato

init

direttamente dal kernel, anche la directory radice non è contenuta in nessuna altra directory

e, come accennato in sez. 1.1.1, viene montata direttamente dal kernel in fase di avvio. Per

questo motivo la directory radice viene ad assumere un ruolo particolare, ed il filesystem che la

supporta deve contenere tutti i programmi di sistema necessari all’avvio, compreso o

init

eventuali sostituti.

Un esempio di questa struttura ad albero, che al contempo ci mostra anche i contenuti delle

directory principali, può essere ottenuto con il comando . Se chiamato senza parametri

tree

questo comando mostra l’albero completo a partire dalla directory corrente, scendendo in tutte

le directory sottostanti; usando l’opzione si può specificare il numero massimo di livelli a cui

-L

scendere, per cui andando su avremo qualcosa del tipo:

/

tree --charset=ASCII -L 2 /

piccardi@hain:~$

/

|-- bin

| |-- bash

...

|-- boot

1. L’architettura di un sistema GNU/Linux 19

| |-- config-3.2.0-1-amd64

...

|-- dev

| |-- autofs

...

|-- etc

| |-- acpi

...

|-- home

| ‘-- piccardi

|-- lib

| |-- discover

...

|-- lib32

| |-- ld-2.13.so

...

24 come accennato l’operazione che rende visibili ai processi i file contenuti all’interno di un filesystem facendoli

comparire all’interno nell’albero dei file viene chiamata il filesystem, torneremo sull’argomento in sez.

montaggio

5.1.3. 1. L’architettura di un sistema GNU/Linux 19

|-- lost+found

|-- media

|-- mnt

|-- opt

|-- proc

| |-- 1

...

|-- root

|-- run

| |-- atd.pid

...

|-- sbin acpi_available

| |--

...

|-- selinux

|-- srv

|-- sys

| |-- block

...

|-- tmp

| |-- ssh-LjWlESaD8958

...

|-- usr

| |-- bin

| |-- games

| |-- include

| |-- lib

| |-- lib32

| |-- local

| |-- sbin

| |-- share

| ‘-- src

|-- var

| |-- backups

| |-- cache

| |-- games

| |-- lib

| |-- local

| |-- lock -> /run/lock

| |-- log

| |-- mail

| |-- opt

| |-- run -> /run

| |-- spool

| ‘-- tmp

‘-- vmlinuz -> boot/vmlinuz-3.2.0-1-amd64

e questo ci mostra il contenuto sommario dei primi due livelli dell’albero, con un esempio dei

file e delle sottodirectory presenti in una versione di test di Debian (Wheezy).

L’organizzazione dell’albero delle directory è standardizzata in maniera molto accurata da

un documento che si chiama (abbreviato in FHS), preso come

Filesystem Hierarchy Standard

25

riferimento da tutte le distribuzioni. Lo standard descrive in dettaglio la struttura dell’albero

25 al momento dell’ultima revisione di questo testo (Febbraio 2013) la versione corrente è la 2.3, rilasciata nel

Standard Base),

2004 e parte delle specifiche LSB (Linux ma è in corso di definizione la versione 3.0, con varie

novità come .

/run

1. L’architettura di un sistema GNU/Linux 21

delle directory e il relativo contenuto, prevedendo una divisione molto rigorosa che permette una

notevole uniformità anche fra distribuzioni diverse; si organizzano cosı̀ in maniera meticolosa ed

ordinata dati, programmi, file di configurazione, documentazione, file degli utenti, ecc.

Directory Contenuto

comandi essenziali.

/bin bootloader.

file statici necessari al

/boot file di dispositivo.

/dev file di configurazione della macchina.

/etc librerie essenziali e moduli del kernel.

/lib mount point per dispositivi rimovibili.

/media mount point montaggi temporanei.

/mnt pacchetti software addizionali.

/opt run-time

dati di volatili.

/run comandi di sistema essenziali.

/sbin dati per i servizi forniti dal sistema.

/srv file temporanei.

/tmp gerarchia secondaria.

/usr dati variabili.

/var

Tabella 1.8: Sottodirectory di obbligatorie per qualunque sistema.

/

In particolare le directory vengono suddivise sulla base di alcuni criteri fondamentali. Il

primo è quello della possibilità di contenere file il cui contenuto può essere modificato (nel qual

caso il filesystem che le contiene deve essere montato in lettura/scrittura) o meno (nel qual caso

il filesystem può essere montato in sola lettura).

Il secondo è quello della possibilità di contenere file come i programmi di sistema che possono

essere condivisi (ad esempio utilizzando un filesystem di rete) fra più stazioni di lavoro o file che

invece sono locali e specifici alla macchina in questione.

Il terzo criterio è quello di contenere o meno comandi o file (configurazioni e file di dispositivo)

che sono necessari all’avvio del sistema, e che pertanto devono essere situati sul filesystem usato

per la directory radice, dato che essi non sarebbero disponibili se posti in filesystem diversi che

possono essere montati solo dopo che il sistema è partito.

Lo standard prevede che debbano essere necessariamente presenti le sottodirectory di spe-

/

cificate in tab. 1.8, mentre quelle di tab. 1.9 sono obbligatorie soltanto qualora si siano installati

26

i sottosistemi a cui essi fanno riferimento (utenti, filesystem, diversi formati binari).

/proc

Un elenco delle specifiche delle caratteristiche e del contenuto di ciascuna delle sottodirectory

di è riportato di seguito; per alcune di esse, come e , sono previste delle ulteriori sotto-

/ /usr /var

gerarchie che definiscono ulteriori dettagli dell’organizzazione dei file. Si è aggiunto all’elenco

anche la directory , che pur non essendo prevista dal FHS è stata adottata da tutte le

/run

distribuzioni più recenti.

Contiene i comandi essenziali del sistema (usati sia dall’amministratore che dagli utenti,

/bin come ), che devono essere disponibili anche quando non ci sono altri filesystem

ls

montati oltre la radice, ad esempio all’avvio o quando si è in (vedi

single user mode

26

le eventuali contengono le versioni delle librerie di sistema in formati binari diversi; le al-

/lib<qual> /lib

ternative sono state usate al tempo della transizione dei programmi dal formato a.out ad ELF, oggi sono usate

principalmente per quei sistemi (come gli AMD-64) che supportano diversi formati binari (32 o 64 bit).

1. L’architettura di un sistema GNU/Linux 21

Directory Contenuto

librerie in formati alternativi.

/lib<qual> home directory degli utenti.

/home home directory dell’amministratore.

/root filesystem virtuale con informazioni su processi

/proc e caratteristiche del sistema.

filesystem virtuale con informazioni su driver

/sys e dispositivi (vedi sez. 5.4.5).

Tabella 1.9: Sottodirectory di obbligatorie solo in presenza dei relativi sottosistemi.

/

sez. 5.3.4). Non deve avere sottodirectory e non può stare su un filesystem diverso da

quello della radice.

Contiene tutti i file necessari al procedimento di boot (immagini del kernel, del

/boot bootloa-

ecc.) eccetto i file di configurazione ed i programmi per l’impostazione

der, ramdisk,

del procedimento stesso, che vanno in . Può stare su qualunque filesystem purché

/sbin

visibile dal (vedi sez. 5.3.1).

bootloader

Contiene i file di dispositivo, che permettono l’accesso alle periferiche. Originariamen-

/dev te doveva stare sullo stesso filesystem della radice, dato che i file di dispositivo sono

necessari alla procedura di avvio. Oggi il contenuto è nella maggior parte dei casi ge-

27

nerato dinamicamente ed è montata su un filesystem temporaneo che viene popolato in

fase di avvio tramite (vedi sez. 5.4.5).

udev 28

Contiene i file di configurazione del sistema e gli script di avvio. Non deve contenere

/etc programmi binari e non può stare su un filesystem diverso da quello della radice. I

file possono essere raggruppati a loro volta in directory; lo standard prevede solo che,

qualora siano installati, siano presenti le directory (per i pacchetti opzionali),

/etc/opt

(per la configurazione di vedi sez. 3.3) e e

X Window,

/etc/X11 /etc/sgml /etc/xml

(per la configurazione di SGML e XML).

Contiene le degli utenti, la sola parte del filesystem (eccetto e

/home home directory /tmp

) su cui gli utenti hanno diritto di scrittura, che viene usata per mantenere i

/var/tmp

loro file personali. Può essere montata su qualunque filesystem.

Contiene le librerie condivise essenziali, usate dai programmi di e , e de- ve

/lib /bin /sbin

essere sullo stesso filesystem della radice. Qualora sia stato installato un kernel

modulare (vedi sez. 5.2.5) i moduli devono essere installati in .

/lib/modules

Contiene i (vedi sez. 5.1.3) per i dispositivi rimovibili, come CDROM, floppy,

/media mount point

chiavette USB, dischi USB o Firewire, ecc. Nelle distribuzioni meno recenti i floppy ed

i CDROM hanno delle directory dedicate, ma con l’introduzione di meccani- smi di

rilevazione automatica dei dispositivi rimovibili (vedi sez. 5.4.5) è stata definita

27 si intende con questo un filesystem di tipo (vedi tab. 5.2) il cui contenuto è mantenuto in memoria.

tmpfs

28 sono un po’ gli equivalenti in ambito Unix (come potrebbe esserlo

script,

gli su cui torneremo in sez. 2.1.5,

una Ferrari in confronto ad una 500) dei file del DOS, una lista di comandi messi in un file (in realtà si

.bat

tratta di un vero linguaggio di programmazione) e fatti eseguire automaticamente.

1. L’architettura di un sistema GNU/Linux 23

questa directory all’interno della quale vengono create le opportune sotto-directory su

cui poi essi vengono montati un maniera automatica.

Contiene i (vedi sez. 5.1.3) per i montaggi temporanei ad uso dell’am-

/mnt mount point

ministratore di sistema; i filesystem di periferiche permanenti con supporti rimovibili

come i floppy o il CDROM che prima venivano tenuti sia in questa directory che di-

rettamente sotto devono essere spostati sotto . Normalmente è vuota e deve

/ /media

essere creata direttamente sotto la radice.

Contiene eventuali pacchetti software aggiuntivi. Può essere su qualunque filesystem.

/opt Un pacchetto deve installarsi nella directory dove è il nome del

package

/opt/package

pacchetto. All’amministratore è riservato l’uso di alcune directory opzionali: ,

/opt/bin

, , , e . File variabili attinenti ai

/opt/doc /opt/include /opt/info /opt/lib /opt/man

suddetti pacchetti devono essere installati in ed i file di configurazione in

/var/opt

, nessun file attinente ai pacchetti deve essere installato al di fuori di queste

/etc/opt

directory.

È il standard del filesystem virtuale . Questo è un filesystem speciale

/proc mount point proc

che permette di accedere a tutta una serie di variabili interne a