Finito col database di accounting
authorSimone Piccardi <piccardi@gnulinux.it>
Sun, 5 May 2002 18:02:17 +0000 (18:02 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sun, 5 May 2002 18:02:17 +0000 (18:02 +0000)
system.tex

index 3671325d509affd44ee7fdc0fc20537fbc2c8a80..657c0d645cc5bada0c1e7b00bf16aa52ef387ce4 100644 (file)
@@ -2,10 +2,11 @@
 \label{cha:system}
 
 In questo capitolo tratteremo varie interfacce che attengono agli aspetti più
 \label{cha:system}
 
 In questo capitolo tratteremo varie interfacce che attengono agli aspetti più
-generali del sistema, come quelle per la gestione di parametri e
-configurazione, quelle per la lettura dei limiti e delle caratteristiche dello
-stesso, quelle per il controllo dell'uso delle risorse da parte dei processi,
-quelle per la gestione dei tempi e degli errori.
+generali del sistema, come quelle per la gestione dei parametri e della
+configurazione dello stesso, quelle per la lettura dei limiti e delle
+caratteristiche, quelle per il controllo dell'uso delle risorse dei processi,
+quelle per la gestione ed il controllo dei filesystem, degli utenti, dei tempi
+e degli errori.
 
 
 
 
 
 
@@ -13,19 +14,19 @@ quelle per la gestione dei tempi e degli errori.
 \label{sec:sys_characteristics}
 
 In questa sezione tratteremo le varie modalità con cui un programma può
 \label{sec:sys_characteristics}
 
 In questa sezione tratteremo le varie modalità con cui un programma può
-ottenere informazioni riguardo alle capacità del sistema. Ogni sistema infatti
-è contraddistinto da un gran numero di limiti e costanti che lo
-caratterizzano, e che possono dipendere da fattori molteplici, come
+ottenere informazioni riguardo alle capacità del sistema. Ogni sistema
+unix-like infatti è contraddistinto da un gran numero di limiti e costanti che
+lo caratterizzano, e che possono dipendere da fattori molteplici, come
 l'architettura hardware, l'implementazione del kernel e delle librerie, le
 opzioni di configurazione.
 
 La definizione di queste caratteristiche ed il tentativo di provvedere dei
 meccanismi generali che i programmi potessero usare per ricavarle è uno degli
 l'architettura hardware, l'implementazione del kernel e delle librerie, le
 opzioni di configurazione.
 
 La definizione di queste caratteristiche ed il tentativo di provvedere dei
 meccanismi generali che i programmi potessero usare per ricavarle è uno degli
-aspetti più complessi e controversi coi cui i vari standard si sono dovuti
-confrontare, spesso con risultati spesso tutt'altro che chiari. Proveremo
-comunque a dare una descrizione dei principali metodi previsti dai vari
-standard per ricavare sia le caratteristiche specifiche del sistema, che
-quelle dei file.
+aspetti più complessi e controversi con cui le diverse standardizzazioni si
+sono dovute confrontare, spesso con risultati spesso tutt'altro che chiari.
+Proveremo comunque a dare una descrizione dei principali metodi previsti dai
+vari standard per ricavare sia le caratteristiche specifiche del sistema, che
+quelle della gestione dei file.
 
 
 \subsection{Limiti e parametri di sistema}
 
 
 \subsection{Limiti e parametri di sistema}
@@ -58,7 +59,7 @@ tramite la funzione \func{sysconf} (che esamineremo in
 \secref{sec:sys_sysconf}).
 
 Lo standard ANSI C definisce dei limiti che sono tutti fissi, pertanto questo
 \secref{sec:sys_sysconf}).
 
 Lo standard ANSI C definisce dei limiti che sono tutti fissi, pertanto questo
-saranno sempre disponibili al momento della compilazione; un elenco, ripreso
+saranno sempre disponibili al momento della compilazione. Un elenco, ripreso
 da \file{limits.h}, è riportato in \tabref{tab:sys_ansic_macro}. Come si può
 vedere per la maggior parte questi limiti attengono alle dimensioni dei dati
 interi, che sono in genere fissati dall'architettura hardware (le analoghe
 da \file{limits.h}, è riportato in \tabref{tab:sys_ansic_macro}. Come si può
 vedere per la maggior parte questi limiti attengono alle dimensioni dei dati
 interi, che sono in genere fissati dall'architettura hardware (le analoghe
@@ -275,10 +276,10 @@ esplicitamente, se ne trova una menzione completa nell'header file
 \label{sec:sys_sysconf}
 
 Come accennato in \secref{sec:sys_limits} quando uno dei limiti o delle
 \label{sec:sys_sysconf}
 
 Come accennato in \secref{sec:sys_limits} quando uno dei limiti o delle
-caratteristiche del sistema può variare, è necessario ottenerne il valore
-attraverso la funzione \func{sysconf}, per non dover essere costretti a
+caratteristiche del sistema può variare, per non dover essere costretti a
 ricompilare un programma tutte le volte che si cambiano le opzioni con cui è
 ricompilare un programma tutte le volte che si cambiano le opzioni con cui è
-compilato il kernel, o alcuni dei parametri modificabili a run time. Il
+compilato il kernel, o alcuni dei parametri modificabili a run time, è
+necessario ottenerne il valore attraverso la funzione \func{sysconf}. Il
 prototipo di questa funzione è:
 \begin{prototype}{unistd.h}{long sysconf(int name)}
   Restituisce il valore del parametro di sistema \param{name}.
 prototipo di questa funzione è:
 \begin{prototype}{unistd.h}{long sysconf(int name)}
   Restituisce il valore del parametro di sistema \param{name}.
@@ -366,9 +367,9 @@ get_child_max(void)
 }
 \end{lstlisting}
 %\normalsize 
 }
 \end{lstlisting}
 %\normalsize 
-ma in realtà in Linux queste macro sono comunque definite e indicando un
-limite generico, per cui è sempre meglio usare i valori restituiti da
-quest'ultima.
+ma in realtà in Linux queste macro sono comunque definite, indicando però un
+limite generico. Per questo motivo è sempre meglio usare i valori restituiti
+da \func{sysconf}.
 
 
 \subsection{I limiti dei file}
 
 
 \subsection{I limiti dei file}
@@ -402,11 +403,11 @@ riportate in \tabref{tab:sys_file_macro}.
   \label{tab:sys_file_macro}
 \end{table}
 
   \label{tab:sys_file_macro}
 \end{table}
 
-Come per i limiti di sistema POSIX.1 detta una serie di valori minimi per
-queste caratteristiche, che ogni sistema che vuole essere conforme deve
-rispettare; le relative macro sono riportate in \tabref{tab:sys_posix1_file},
-e per esse vale lo stesso discorso fatto per le analoghe di
-\tabref{tab:sys_posix1_general}.
+Come per i limiti di sistema, lo standard POSIX.1 detta una serie di valori
+minimi anche per queste caratteristiche, che ogni sistema che vuole essere
+conforme deve rispettare; le relative macro sono riportate in
+\tabref{tab:sys_posix1_file}, e per esse vale lo stesso discorso fatto per le
+analoghe di \tabref{tab:sys_posix1_general}.
 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering
@@ -446,10 +447,10 @@ implementazioni moderne.
 \label{sec:sys_pathconf}
 
 In generale i limiti per i file sono molto più soggetti ad essere variabili
 \label{sec:sys_pathconf}
 
 In generale i limiti per i file sono molto più soggetti ad essere variabili
-rispetto ai precedenti limiti generali del sistema; ad esempio parametri come
-la lunghezza del nome del file o il numero di link possono variare da
-filesystem a filesystem; per questo motivo questi limiti devono essere sempre
-controllati con la funzione \func{pathconf}, il cui prototipo è:
+rispetto ai limiti generali del sistema; ad esempio parametri come la
+lunghezza del nome del file o il numero di link possono variare da filesystem
+a filesystem; per questo motivo questi limiti devono essere sempre controllati
+con la funzione \func{pathconf}, il cui prototipo è:
 \begin{prototype}{unistd.h}{long pathconf(char *path, int name)}
   Restituisce il valore del parametro \param{name} per il file \param{path}.
   
 \begin{prototype}{unistd.h}{long pathconf(char *path, int name)}
   Restituisce il valore del parametro \param{name} per il file \param{path}.
   
@@ -461,7 +462,7 @@ controllati con la funzione \func{pathconf}, il cui prototipo 
 E si noti come la funzione in questo caso richieda un parametro che specifichi
 a quale file si fa riferimento, dato che il valore del limite cercato può
 variare a seconda del filesystem. Una seconda versione della funzione,
 E si noti come la funzione in questo caso richieda un parametro che specifichi
 a quale file si fa riferimento, dato che il valore del limite cercato può
 variare a seconda del filesystem. Una seconda versione della funzione,
-\func{fpathconf}, opera su un file descriptor invece che su un pathname, il
+\func{fpathconf}, opera su un file descriptor invece che su un pathname. Il
 suo prototipo è:
 \begin{prototype}{unistd.h}{long fpathconf(int fd, int name)}
   Restituisce il valore del parametro \param{name} per il file \param{fd}.
 suo prototipo è:
 \begin{prototype}{unistd.h}{long fpathconf(int fd, int name)}
   Restituisce il valore del parametro \param{name} per il file \param{fd}.
@@ -477,7 +478,7 @@ suo prototipo 
 \label{sec:sys_uname}
 
 Un'altra funzione che si può utilizzare per raccogliere informazioni sia
 \label{sec:sys_uname}
 
 Un'altra funzione che si può utilizzare per raccogliere informazioni sia
-riguardo al sistema che al computer su cui esso sta girando è \func{uname}, il
+riguardo al sistema che al computer su cui esso sta girando è \func{uname}; il
 suo prototipo è:
 \begin{prototype}{sys/utsname.h}{int uname(struct utsname *info)}
   Restituisce informazioni sul sistema nella struttura \param{info}.
 suo prototipo è:
 \begin{prototype}{sys/utsname.h}{int uname(struct utsname *info)}
   Restituisce informazioni sul sistema nella struttura \param{info}.
@@ -530,10 +531,11 @@ In generale si tenga presente che le dimensioni delle stringe di una
 \macro{\_UTSNAME\_LENGTH} per i campi standard e
 \macro{\_UTSNAME\_DOMAIN\_LENGTH} per quello specifico per il nome di dominio;
 altri sistemi usano nomi diversi come \macro{SYS\_NMLN} o \macro{\_SYS\_NMLN}
 \macro{\_UTSNAME\_LENGTH} per i campi standard e
 \macro{\_UTSNAME\_DOMAIN\_LENGTH} per quello specifico per il nome di dominio;
 altri sistemi usano nomi diversi come \macro{SYS\_NMLN} o \macro{\_SYS\_NMLN}
-or \macro{UTSLEN} che possono avere valori diversi; nel caso di Linux
+or \macro{UTSLEN} che possono avere valori diversi. Nel caso di Linux
 \func{uname} corrisponde in realtà a 3 system call diverse, le prime due usano
 \func{uname} corrisponde in realtà a 3 system call diverse, le prime due usano
-delle lunghezze delle stringhe di 9 e 65 byte; la terza 65, restituisce anche
-l'ultimo campo con una lunghezza di 257 byte.
+rispettivamente delle lunghezze delle stringhe di 9 e 65 byte; la terza usa
+anch'essa 65 byte, ma restituisce anche l'ultimo campo, \var{domainname}, con
+una lunghezza di 257 byte.
 
 
 \section{Opzioni e configurazione del sistema}
 
 
 \section{Opzioni e configurazione del sistema}
@@ -596,7 +598,7 @@ I parametri a cui la funzione permettere di accedere sono organizzati in
 maniera gerarchica all'interno un albero; per accedere ad uno di essi occorre
 specificare un cammino attraverso i vari nodi dell'albero, in maniera analoga
 a come avviene per la risoluzione di un pathname (da cui l'uso alternativo del
 maniera gerarchica all'interno un albero; per accedere ad uno di essi occorre
 specificare un cammino attraverso i vari nodi dell'albero, in maniera analoga
 a come avviene per la risoluzione di un pathname (da cui l'uso alternativo del
-filesystem \file{/proc} che vedremo dopo).
+filesystem \file{/proc}, che vedremo dopo).
 
 Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
 arriva ad identificare un parametro specifico è passato alla funzione
 
 Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
 arriva ad identificare un parametro specifico è passato alla funzione
@@ -721,7 +723,7 @@ loro dati sono generati al volo ad ogni lettura, e passati al kernel ad ogni
 scrittura. 
 
 Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
 scrittura. 
 
 Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
-una delle stringhe riportate in \file{/proc/filesystems}, che contiene
+una delle stringhe riportate nel file \file{/proc/filesystems}, che contiene
 l'elenco dei filesystem supportati dal kernel; nel caso si sia indicato uno
 dei filesystem virtuali, il contenuto di \param{source} viene ignorato.
 
 l'elenco dei filesystem supportati dal kernel; nel caso si sia indicato uno
 dei filesystem virtuali, il contenuto di \param{source} viene ignorato.
 
@@ -731,8 +733,8 @@ precedente contenuto di detta directory viene mascherato dal contenuto della
 directory radice del filesystem montato.
 
 Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
 directory radice del filesystem montato.
 
 Dal kernel 2.4.x inoltre è divenuto possibile sia spostare atomicamente un
-\textit{mount point} da una directory ad un'altra, che montare in diversi
-\textit{mount point} lo stesso filesystem, che montare più filesystem sullo
+\textit{mount point} da una directory ad un'altra, sia montare in diversi
+\textit{mount point} lo stesso filesystem, sia montare più filesystem sullo
 stesso \textit{mount point} (nel qual caso vale quanto appena detto, e solo il
 contenuto dell'ultimo filesystem montato sarà visibile).
 
 stesso \textit{mount point} (nel qual caso vale quanto appena detto, e solo il
 contenuto dell'ultimo filesystem montato sarà visibile).
 
@@ -901,8 +903,8 @@ nome del filesystem stesso.
 
 
 Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
 
 
 Le \acr{glibc} provvedono infine una serie di funzioni per la gestione dei due
-pfile standard \file{/etc/fstab} e \file{/etc/mtab}, che convenzionalmente sono
-usati in quasi tutti i sistemi unix per mantenere rispettivamente le
+file standard \file{/etc/fstab} e \file{/etc/mtab}, che convenzionalmente sono
+usati in quasi tutti i sistemi unix-like per mantenere rispettivamente le
 informazioni riguardo ai filesystem da montare e a quelli correntemente
 montati. Le funzioni servono a leggere il contenuto di questi file in
 opportune strutture \var{struct fstab} e \var{struct mntent}, e, per
 informazioni riguardo ai filesystem da montare e a quelli correntemente
 montati. Le funzioni servono a leggere il contenuto di questi file in
 opportune strutture \var{struct fstab} e \var{struct mntent}, e, per
@@ -919,14 +921,18 @@ tralasceremo la trattazione, rimandando al manuale delle \acr{glibc}
 \subsection{La gestione di utenti e gruppi}
 \label{sec:sys_user_group}
 
 \subsection{La gestione di utenti e gruppi}
 \label{sec:sys_user_group}
 
-L'ultimo argomento di questa sezione è quello che riguarda le funzioni
-utilizzate per gestire utenti e gruppi all'interno del sistema.
 Tradizionalmente l'informazione per la gestione di utenti e gruppi veniva
 Tradizionalmente l'informazione per la gestione di utenti e gruppi veniva
-tenuta tutta nei due file di testo \file{/etc/passwd} ed \file{/etc/group};
-oggi la maggior parte delle distribuzioni di Linux usa la libreria PAM (sigla
-che sta \textit{Pluggable Authentication Method}) che permette di separare
-completamente i meccanismi di gestione degli utenti (autenticazione,
-riconoscimento, ecc.) dalle modalità in cui i relativi dati vengono mantenuti.
+tenuta tutta nei due file di testo \file{/etc/passwd} ed \file{/etc/group}, e
+tutte le funzioni facevano riferimento ad essi.  Oggi la maggior parte delle
+distribuzioni di Linux usa la libreria PAM (sigla che sta \textit{Pluggable
+  Authentication Method}) che permette di separare completamente i meccanismi
+di gestione degli utenti (autenticazione, riconoscimento, ecc.) dalle modalità
+in cui i relativi dati vengono mantenuti, per cui pur restando in gran parte
+le stesse\footnote{in genere quello che viene cambiato è l'informazione usata
+  per l'autenticazione, che non è più necessariamente una password criptata da
+  verificare, ma può assumere le forme più diverse, come impronte digitali,
+  chiavi elettroniche, ecc.}, le informazioni non sono più necessariamente
+mantenute in quei file.
 
 In questo paragrafo ci limiteremo comunque alle funzioni classiche per la
 lettura delle informazioni relative a utenti e gruppi previste dallo standard
 
 In questo paragrafo ci limiteremo comunque alle funzioni classiche per la
 lettura delle informazioni relative a utenti e gruppi previste dallo standard
@@ -981,10 +987,11 @@ struct passwd {
 \end{figure}
 
 La struttura usata da entrambe le funzioni è allocata staticamente, per questo
 \end{figure}
 
 La struttura usata da entrambe le funzioni è allocata staticamente, per questo
-motivo viene sovrascritta ad ogni nuova invocazione, così come le stringhe a
-cui essa fa riferimento. Ovviamente queste funzioni non sono rientranti, ne
-esistono quindi anche due versioni alternative (denotate dalla solita
-estensione \code{\_r}), i cui prototipi sono:
+motivo viene sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la
+memoria dove sono scritte le stringhe a cui i puntatori in essa contenuti
+fanno riferimento. Ovviamente questo implica che dette funzioni non posono
+essere rientranti, per cui ne esistono anche due versioni alternative
+(denotate dalla solita estensione \code{\_r}), i cui prototipi sono:
 \begin{functions}
   \headdecl{pwd.h} 
   
 \begin{functions}
   \headdecl{pwd.h} 
   
@@ -1007,11 +1014,12 @@ la memoria necessaria a contenere le informazioni. In particolare i valori
 della struttura \var{passwd} saranno restituiti all'indirizzo \param{password}
 mentre la memoria allocata all'indirizzo \param{buffer}, per un massimo di
 \param{buflen} byte, sarà utilizzata per contenere le stringhe puntate dai
 della struttura \var{passwd} saranno restituiti all'indirizzo \param{password}
 mentre la memoria allocata all'indirizzo \param{buffer}, per un massimo di
 \param{buflen} byte, sarà utilizzata per contenere le stringhe puntate dai
-campi di \param{password}; infine all'indirizzo puntato da \param{result}
+campi di \param{password}. Infine all'indirizzo puntato da \param{result}
 viene restituito il puntatore ai dati ottenuti, cioè \param{buffer} nel caso
 l'utente esista, o \macro{NULL} altrimenti.  Qualora i dati non possano essere
 viene restituito il puntatore ai dati ottenuti, cioè \param{buffer} nel caso
 l'utente esista, o \macro{NULL} altrimenti.  Qualora i dati non possano essere
-contenuti in \param{buflen} byte la funzione fallirà restituendo
-\macro{ERANGE} (e \param{result} sarà comunque settato a \macro{NULL}).
+contenuti nei byte specificati da \param{buflen}, la funzione fallirà
+restituendo \macro{ERANGE} (e \param{result} sarà comunque settato a
+\macro{NULL}).
 
 Del tutto analoghe alle precedenti sono le funzioni \func{getgrnam} e
 \func{getgrgid} (e le relative analoghe rientranti con la stessa estensione
 
 Del tutto analoghe alle precedenti sono le funzioni \func{getgrnam} e
 \func{getgrgid} (e le relative analoghe rientranti con la stessa estensione
@@ -1104,47 +1112,56 @@ database che sia tenuto su un file che abbia il formato classico di
 \end{table}
 
 Dato che ormai la gran parte delle distribuzioni di Linux utilizzano PAM, che
 \end{table}
 
 Dato che ormai la gran parte delle distribuzioni di Linux utilizzano PAM, che
-come minimo usa almeno le \textit{shadow password}, quindi con delle modifiche
-rispetto al formato classico di \file{/etc/passwd}, le funzioni che danno la
-capacità scrivere delle voci nel database (\func{putpwent} e \func{putgrent})
-non permettono di specificarle in maniera completa. Per questo motivo l'uso di
-queste funzioni è deprecato in favore dell'uso di PAM, per cui ci limitiamo a
-elencarle in \tabref{tab:sys_passwd_func}, rimandando chi fosse interessato
-alle man page e al manuale delle \acr{glibc} per i dettagli del funzionamento.
+come minimo usa almeno le \textit{shadow password} (quindi con delle modifiche
+rispetto al formato classico di \file{/etc/passwd}), le funzioni che danno la
+capacità scrivere delle voci nel database (cioè \func{putpwent} e
+\func{putgrent}) non permettono di effettuarne una specificazione in maniera
+completa. Per questo motivo l'uso di queste funzioni è deprecato in favore
+dell'uso di PAM, ci limiteremo pertanto ad elencarle in
+\tabref{tab:sys_passwd_func}, rimandando chi fosse interessato alle rispettive
+man page e al manuale delle \acr{glibc} per i dettagli del loro funzionamento.
 
 
 
 \subsection{Il database di accounting}
 \label{sec:sys_accounting}
 
 
 
 
 \subsection{Il database di accounting}
 \label{sec:sys_accounting}
 
-Un altro insieme di funzioni utili è quello che permette di accedere ai dati
-del database di \textit{accounting} degli utenti, che mantiene la traccia di
-chi si è collegato al sistema e di che è correntemente collegato, insieme alle
-informazioni, per ciascun terminale, di chi ci è collegato, da che ora,
-dell'\acr{uid} della shell di login, ed una serie di altre informazioni
-relativa al sistema come il run-level, l'orario dell'ultimo riavvio, ed altre. 
-
-Le informazioni vengono mantenute nei due file \file{/var/run/utmp} e
+L'ultimo insieme di funzioni relative alla gestione del sistema che
+esamineremo è quello che permette di accedere ai dati del database di
+\textit{accounting}.  In esso vengono mantenute una serie di informazioni
+storiche relative sia agli utenti che si sono collegati al sistema, (tanto per
+quelli correntemente collegati, che per la registrazione degli accessi
+precedenti), sia relative all'intero sistema, come il momento di lancio di
+processi da parte di \cmd{init}, il cambiamento dell'orologio di sistema, il
+cambiamento di runlevel o il riavvio della macchina.
+
+I dati vengono usualmente\footnote{questa è la locazione specificata dal
+  \textit{Linux Filesystem Hierarchy Standard}, adottato dalla gran parte
+  delle distribuzioni.} memorizzati nei due file \file{/var/run/utmp} e
 \file{/var/log/wtmp}. Quando un utente si collega viene aggiunta una voce a
 \file{/var/log/wtmp}. Quando un utente si collega viene aggiunta una voce a
-\file{/var/run/utmp}; la voce vi resta fino al logout, quando viene cancellata
-e spostata in \file{/var/log/wtmp}.
+\file{/var/run/utmp} in cui viene memorizzato il nome di login, il terminale
+da cui ci si collega, l'\acr{uid} della shell di login, l'orario della
+connessione ed altre informazioni.  La voce resta nel file fino al logout,
+quando viene cancellata e spostata in \file{/var/log/wtmp}.
 
 In questo modo il primo file viene utilizzato per registrare sta utilizzando
 
 In questo modo il primo file viene utilizzato per registrare sta utilizzando
-il sistema al momento corrente, mentre il secondo mantiene la storia delle
-attività degli utenti. A quest'ultimo vengono anche aggiunte delle voci
-speciali per tenere conto dei cambiamenti di runlevel, del riavvio della
-macchina, e di altri eventi di sistema.
+il sistema al momento corrente, mentre il secondo mantiene la registrazione
+delle attività degli utenti. A quest'ultimo vengono anche aggiunte delle voci
+speciali per tenere conto dei cambiamenti del sistema, come la modifica del
+runlevel, il riavvio della macchina, ecc. Tutte queste informazioni sono
+descritte in dettaglio nel manuale delle \acr{glibc}.
 
 Questi file non devono mai essere letti direttamente, ma le informazioni che
 contengono possono essere ricavate attraverso le opportune funzioni di
 
 Questi file non devono mai essere letti direttamente, ma le informazioni che
 contengono possono essere ricavate attraverso le opportune funzioni di
-libreria. Queste sono analoghe alle precedenti per il database delle password,
-solo che la struttura del database è molto più complessa, dato che contiene
-vari tipi di informazione.
-
-Le prime tre funzioni, \func{utmpname}, \func{setutent} e \func{endutent},
-servono a aprire e chiudere il database, e a specificare il file su cui esso è
-mantenuto (in caso questo non venga specificato viene usato il valore standard
-\macro{\_PATH\_UTMP} che è definito in \file{paths.h}. Il loro prototipi sono:
+libreria. Queste sono analoghe alle precedenti (vedi
+\tabref{tab:sys_passwd_func}) usate per accedere al database degli utenti,
+solo che in questo caso la struttura del database di accounting è molto più
+complessa, dato che contiene diversi tipi di informazione.
+
+Le prime tre funzioni, \func{setutent}, \func{endutent} e \func{utmpname}
+servono rispettivamente a aprire e a chiudere il file che contiene il
+database, e a specificare su quale file esso viene mantenuto. I loro prototipi
+sono:
 \begin{functions}
   \headdecl{utmp.h} 
   
 \begin{functions}
   \headdecl{utmp.h} 
   
@@ -1160,6 +1177,18 @@ mantenuto (in caso questo non venga specificato viene usato il valore standard
   \bodydesc{Le funzioni non ritornano codici di errore.}
 \end{functions}
 
   \bodydesc{Le funzioni non ritornano codici di errore.}
 \end{functions}
 
+In caso questo non venga specificato nessun file viene usato il valore
+standard \macro{\_PATH\_UTMP} (che è definito in \file{paths.h}); in genere
+\func{utmpname} prevede due possibili valori:
+\begin{basedescript}{\desclabelwidth{2.0cm}}
+\item[\macro{\_PATH\_UTMP}] Specifica il database di accounting per gli utenti
+  correntemente collegati.
+\item[\macro{\_PATH\_WTMP}] Specifica il database di accounting per l'archivio
+  storico degli utenti collegati.
+\end{basedescript}
+corrispondenti ai file \file{/var/run/utmp} e \file{/var/log/wtmp} visti in
+precedenza.
+
 Una volta aperto il file si può eseguire una scansione leggendo o scrivendo
 una voce con le funzioni \func{getutent}, \func{getutid}, \func{getutline} e 
 \func{pututline}, i cui prototipi sono:
 Una volta aperto il file si può eseguire una scansione leggendo o scrivendo
 una voce con le funzioni \func{getutent}, \func{getutid}, \func{getutline} e 
 \func{pututline}, i cui prototipi sono:
@@ -1253,12 +1282,59 @@ corripondente al valore del campo \var{ut\_id} specificato in \param{ut}.
   \label{tab:sys_ut_type}
 \end{table}
 
   \label{tab:sys_ut_type}
 \end{table}
 
-Infine \func{getutline} esegue la ricerca sulle voci che hanno \var{ut\_type}
-uguale a \macro{LOGIN\_PROCESS} o \macro{USER\_PROCESS}, restituendo la prima
-che corrisponde al valore di \var{ut\_line}. Lo stesso criterio di ricerca è
-usato da \func{pututline} per trovare uno spazio dove inserire la voce
-specificata, qualora non sia trovata la voce viene aggiunta in coda al
-database.
+La funzione \func{getutline} esegue la ricerca sulle voci che hanno
+\var{ut\_type} uguale a \macro{LOGIN\_PROCESS} o \macro{USER\_PROCESS},
+restituendo la prima che corrisponde al valore di \var{ut\_line}, che
+specifica il device\footnote{espresso senza il \file{/dev/} iniziale.} di
+terminale che interessa. Lo stesso criterio di ricerca è usato da
+\func{pututline} per trovare uno spazio dove inserire la voce specificata,
+qualora non sia trovata la voce viene aggiunta in coda al database.
+
+In generale occorre però tenere conto che queste funzioni non sono
+completamente standardizzate, e che in sistemi diversi possono esserci
+differenze; ad esempio \func{pututline} restituisce \code{void} in vari
+sistemi (compreso Linux, fino alle \acr{libc5}). Qui seguiremo la sintassi
+fornita dalle \acr{glibc}, ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno
+introdotto delle nuove strutture (e relativi file) di tipo \code{utmpx}, che
+sono un sovrainsieme di \code{utmp}. 
+
+Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende
+inutili queste nuove strutture; pertanto esse e le relative funzioni di
+gestione (\func{getutxent}, \func{getutxid}, \func{getutxline},
+\func{pututxline}, \func{setutxent} e \func{endutxent}) sono ridefinite come
+sinonimi delle funzioni appena viste.
+
+Come visto in \secref{sec:sys_user_group}, l'uso di strutture allocate
+staticamente rende le funzioni di lettura non rientranti; per questo motivo le
+\acr{glibc} forniscono anche delle versioni rientranti: \func{getutent\_r},
+\func{getutid\_r}, \func{getutline\_r}, che invece di restituire un puntatore
+restituiscono un intero e prendono due argomenti aggiuntivi. Le funzioni si
+comportano esattamente come le analoge non rientranti, solo che restituiscono
+il risultato all'indirizzo specificato dal primo argomento aggiuntivo (di tipo
+\code{struct utmp *buffer}) mentre il secondo (di tipo \code{struct utmp
+  **result)} viene usato per restituire il puntatore allo stesso buffer.
+
+Infine le \acr{glibc} forniscono come estensione per la scrittura delle voci
+in \file{wmtp} altre due funzioni, \func{updwtmp} e \func{logwtmp}, i cui
+prototipi sono:
+\begin{functions}
+  \headdecl{utmp.h} 
+  
+  \funcdecl{void updwtmp(const char *wtmp\_file, const struct utmp *ut)}
+  Aggiunge la voce \param{ut} nel database di accounting \file{wmtp}.
+  
+  \funcdecl{void logwtmp(const char *line, const char *name, const char
+    *host)} Aggiunge nel database di accounting una voce con i valori
+  specificati.
+
+  \bodydesc{Le funzioni ritornano il puntatore ad una struttura \var{utmp} in
+    caso di successo e \macro{NULL} in caso di errore.}
+\end{functions}
+
+La prima funzione permette l'aggiunta di una voce a \file{wmtp} specificando
+direttamente una struttura \type{utmp}, mentre la seconda utilizza gli
+argomenti \param{line}, \param{name} e \param{host} per costruire la voce che
+poi aggiunge chiamando \func{updwtmp}.
 
 
 \section{Limitazione ed uso delle risorse}
 
 
 \section{Limitazione ed uso delle risorse}