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 kernel (il nucleo del sistema), cui si demanda la gestione delle risorse 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 user space, che è l’ambiente a disposizione degli utenti, in cui vengono eseguiti i processi, e il kernel space, che è l’ambiente in cui viene eseguito il kernel. I 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 space, in cui essi vedono 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 system call. Lo standard in questo caso si chiama POSIX.1; ma oltre a quelle dello standard Linux supporta ulteriori system call, relative a sue estensioni specifiche.

Le system call e tutta una serie di ulteriori funzioni di base sono tradizionalmente raccolte in 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 GNU C library (chiamata in breve glibc), 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 scheduler, è deputata 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 VM (sigla che sta per Virtual Memory), si 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 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 drivers e 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 user space e kernel space è che in 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 Windows, sul MacOS o sul VMS. All’avvio il kernel monta quella che si chiama la directory radice (o root directory) dell’albero, che viene indicata con “/”, tutti i restanti dischi, il CDROM e qualunque altro dispositivo contenente file, verranno poi montati (vedi sez. 5.1.3) successivamente in opportune sotto-directory della radice.

Come per il processo iniziale init, che non è figlio di nessun altro processo e viene lanciato 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 init o 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 tree. Se chiamato senza parametri questo comando mostra l’albero completo a partire dalla directory corrente, scendendo in tutte le directory sottostanti; usando l’opzione -L si può specificare il numero massimo di livelli a cui 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 montaggio il filesystem, torneremo sull’argomento in sez. 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 Filesystem Hierarchy Standard (abbreviato in FHS), preso come 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.

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 / specificate 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 /usr e /var, sono previste delle ulteriori sotto-gerarchie che definiscono ulteriori dettagli dell’organizzazione dei file. Si è aggiunto all’elenco anche la directory /run, che pur non essendo prevista dal FHS è stata adottata da tutte le distribuzioni più recenti.

Contiene i comandi essenziali del sistema (usati sia dall’amministratore che dagli utenti, /bin come ls), che devono essere disponibili anche quando non ci sono altri filesystem montati oltre la radice, ad esempio all’avvio o quando si è in single user mode (vedi 26 le eventuali /lib<qual> contengono le versioni delle librerie di sistema in formati binari diversi; le alternative /lib 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

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 bootloader, ramdisk, ecc.) eccetto i file di configurazione ed i programmi per l’impostazione del procedimento stesso, che vanno in /sbin. Può stare su qualunque filesystem purché visibile dal bootloader (vedi sez. 5.3.1).

Contiene i file di dispositivo, che permettono l’accesso alle periferiche. Originariamente /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 udev (vedi sez. 5.4.5). 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 /etc/opt (per i pacchetti opzionali), /etc/X11 (per la configurazione di eX Window, vedi sez. 3.3) e /etc/sgml e /etc/xml (per la configurazione di SGML e XML).

Contiene le home directory degli utenti, la sola parte del filesystem (eccetto /home /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 /bin e /sbin, e deve /lib 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 mount point (vedi sez. 5.1.3) per i dispositivi rimovibili, come CDROM, floppy, /media 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 meccanismi di rilevazione automatica dei dispositivi rimovibili (vedi sez. 5.4.5) è stata definita 27 si intende con questo un filesystem di tipo tmpfs (vedi tab. 5.2) il cui contenuto è mantenuto in memoria. 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 .bat del DOS, una lista di comandi messi in un file (in realtà si 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 mount point (vedi sez. 5.1.3) per i montaggi temporanei ad uso dell’amministratore 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 direttamente sotto / devono essere spostati sotto /media. Normalmente è vuota e deve essere creata direttamente sotto la radice.

Contiene eventuali pacchetti software aggiuntivi. Può essere su qualunque filesystem. /opt Un pacchetto deve installarsi nella directory /opt/package dove package è il nome del pacchetto. All’amministratore è riservato l’uso di alcune directory opzionali: /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib e /opt/man. File variabili attinenti ai suddetti pacchetti devono essere installati in /var/opt, ed i file di configurazione in /etc/opt, nessun file attinente ai pacchetti deve essere installato al di fuori di queste directory.

È il mount point standard del filesystem virtuale proc. Questo è un filesystem speciale /proc che permette di accedere a tutta una serie di variabili interne a