[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]


Capitolo 350.   Accorgimenti per usare GNU/Linux nella didattica di massa

La gestione di un laboratorio munito di elaboratori in una scuola media è problematica, a causa di diversi fattori: l'età degli studenti; il poco tempo a disposizione degli insegnanti; la necessità di svolgere una gran mole di esercitazioni specifiche.

GNU/Linux è un sistema operativo sofisticato e sotto questo aspetto non è adatto a un ambiente del genere. In questo capitolo si raccolgono delle idee su possibili soluzioni ai problemi tipici di un tale laboratorio.

350.1   Utente speciale per uno scopo speciale

Quando si vuole permettere agli utenti comuni di compiere attività che altrimenti sarebbero esclusivamente di competenza dell'utente root, si può utilizzare sudo, oppure si può creare un utente apposito nell'elenco del file /etc/passwd, al quale, invece di associare una shell, si associa il programma o lo script che si vuole fare eseguire.

CIAO::0:0:Esempio generico:/:/etc/script/.CIAO

L'esempio mostra una riga del file /etc/passwd in cui viene definito l'utente CIAO, senza parola d'ordine, con lo stesso UID e GID dell'utente root, avendo di conseguenza gli stessi privilegi, al quale viene però associata la directory / (per motivi di sicurezza è meglio evitare l'uso di /tmp/), dove al posto di una shell si abbina lo script /etc/script/.CIAO.

In questo modo, accedendo con il nominativo CIAO, si esegue lo script /etc/script/.CIAO. Al termine dell'esecuzione dello script, la sessione di lavoro come utente CIAO termina.

Il meccanismo rende il sistema molto poco sicuro, ma ha il vantaggio di essere un modo semplice per l'esecuzione di alcuni comandi che sono normalmente di competenza dell'utente root.

È importante che la dichiarazione del vero utente root sia precedente a quella di questi finti utenti root.

Per fare in modo che gli eventuali sistemi di sicurezza abbandonino ogni resistenza, è probabile che si debba includere l'ipotetico programma /etc/script/.CIAO nel file /etc/shells. Inoltre, dovrebbe essere evidente che in una situazione del genere non sia sensata l'attivazione delle password shadow (si veda anche quanto scritto a proposito del file /etc/login.defs nel capitolo dedicato proprio alle password shadow).

Se si intende utilizzare questo tipo di utente attraverso un programma per l'accesso remoto (rlogin, rsh, telnet o rexec) è necessario che il file /etc/securetty contenga l'indicazione dei terminali da cui questo pseudo utente root può accedere.

350.2   Spegnimento da parte di utenti comuni

Generalmente, un utente comune non è autorizzato a utilizzare shutdown o equivalenti, per chiudere l'attività di GNU/Linux. Però, in certi casi, può essere utile che ciò sia possibile. Il modo più semplice di permettere agli utenti comuni di avviarlo, è attribuirgli il permesso SUID, come nell'esempio seguente:

chmod u+s /sbin/shutdown

Eventualmente si può completare la cosa creando un collegamento nella directory /bin/ in modo che sia accessibile facilmente agli utenti comuni, senza bisogno di indicarne il percorso.

ln -s /sbin/shutdown /bin/shutdown

Viene mostrata anche una tecnica diversa che si basa sul trucco dell'utente speciale descritta sopra. Questo modo può sembrare più laborioso e inutile; in realtà ci sono dei vantaggi, in particolare la possibilità di controllo sull'operazione stessa. Come è già stato mostrato nella sezione precedente, si aggiunge l'utente SPEGNIMI nel file /etc/passwd:

SPEGNIMI::0:0:Spegnimento dell'elaboratore:/:/etc/script/.SPEGNIMI

Quindi, lo script /etc/script/.SPEGNIMI potrebbe essere preparato in modo da poter abilitare o disabilitare la possibilità di eseguire la procedura di arresto del sistema.

#!/bin/bash
#======================================================================
# .SPEGNIMI
#======================================================================

    #------------------------------------------------------------------
    # Verifica la presenza del file SPEGNIMI.OK
    #------------------------------------------------------------------
    if [ -f /etc/script/data/SPEGNIMI.OK ]
    then
        #--------------------------------------------------------------
        # Il file esiste e si può spegnere.
        # Esegue lo shutdown con un'attesa di 10 secondi.
        #--------------------------------------------------------------
        sleep 10s
        /sbin/shutdown -h now
    else
        #--------------------------------------------------------------
        # L'operazione di spegnimento non è consentita.
        #--------------------------------------------------------------
        echo "L'operazione richiesta di spegnimento non è consentita!"
    fi

Lo script deve essere accessibile in tutti i modi solo all'utente root e in nessun modo agli altri utenti (07008).

L'esecuzione di shutdown dipende quindi dalla presenza del file /etc/script/data/SPEGNIMI.OK. In questo modo è possibile regolare semplicemente l'accessibilità a questa funzione di spegnimento.

Per utilizzare in pratica questo sistema, si può agire attraverso un accesso locale o remoto. Attraverso un accesso normale è possibile spegnere il sistema: basta utilizzare l'utente SPEGNIMI, per il quale non è richiesta alcuna parola d'ordine.

Attraverso rlogin è possibile attivare una connessione con lo stesso elaboratore su cui si sta operando, ottenendone lo spegnimento. L'esempio seguente utilizza hostname per determinare il nome dell'elaboratore: è importante che questo restituisca un nome corretto.

rlogin -l SPEGNIMI `hostname`

Nello stesso modo si può spegnere un elaboratore attraverso la rete da un'altra posizione.

rlogin -l SPEGNIMI indirizzo_da_spegnere

Per rendere più facile il meccanismo, si può creare uno script ulteriore con lo stesso nome dell'utente fittizio SPEGNIMI.

#!/bin/sh
#======================================================================
# SPEGNIMI
#======================================================================

    rlogin -l SPEGNIMI `hostname`

In tal modo si utilizza lo stesso termine, sia in presenza di una richiesta di accesso, sia durante una sessione di lavoro normale.

Per avviare la procedura di arresto del sistema su un gruppo di elaboratori in un colpo solo, si può creare uno script che esegue una serie di rlogin su tutti gli elaboratori interessati.

#!/bin/sh
#======================================================================
# SPEGNITUTTI
#======================================================================

    rlogin -l SPEGNIMI host01.brot.dg &
    rlogin -l SPEGNIMI host02.brot.dg &
    rlogin -l SPEGNIMI host03.brot.dg &
    rlogin -l SPEGNIMI host04.brot.dg &
    rlogin -l SPEGNIMI host05.brot.dg &
    #...

In alternativa, se per qualunque motivo si ha difficoltà a utilizzare rlogin o rsh come si vorrebbe, si può utilizzare Secure Shell (capitolo 202), configurandola in modo che utilizzi una forma di autenticazione che non richieda l'inserimento di una parola d'ordine. Lo script potrebbe essere modificato nel modo seguente:

#!/bin/sh
#======================================================================
# SPEGNITUTTI
#======================================================================

    ssh -l SPEGNIMI host01.brot.dg &
    ssh -l SPEGNIMI host02.brot.dg &
    ssh -l SPEGNIMI host03.brot.dg &
    ssh -l SPEGNIMI host04.brot.dg &
    ssh -l SPEGNIMI host05.brot.dg &
    #...

350.3   Autorizzare chiunque ad aggiungersi come nuovo utente

Normalmente, non è sensato concedere a chiunque di registrarsi da solo all'interno di un sistema, ma su un elaboratore destinato alla didattica, in un ambiente in cui non si vuole utilizzare il NIS, questo potrebbe essere più che giustificato. Con la tecnica già vista nella sezione, si aggiunge l'utente AGGIUNGI.

AGGIUNGI::0:0:Aggiunta nuovo utente:/:/etc/script/.AGGIUNGI

Lo script /etc/script/.AGGIUNGI potrebbe essere preparato in modo da poter abilitare o disabilitare la possibilità di eseguire il programma adduser.

Il programma adduser non è necessariamente presente con questo nome e con lo stesso comportamento in tutte le distribuzioni GNU/Linux. In questi esempi si suppone che adduser accetti un solo argomento: il nome dell'utente da aggiungere.

#! /bin/bash
#======================================================================
# .AGGIUNGI
#======================================================================

#======================================================================
# Inizio.
#======================================================================

    #------------------------------------------------------------------
    # Verifica la presenza del file AGGIUNGI.OK
    #------------------------------------------------------------------
    if [ -f /etc/script/data/AGGIUNGI.OK ]
    then
        #--------------------------------------------------------------
        # Il file esiste e si può aggiungere l'utente.
        # Si inizia ottenendo il nome da utilizzare.
        #--------------------------------------------------------------
        echo "Inserisci il nome dell'utente."
        echo "Si possono utilizzare al massimo otto caratteri."
        read
        #--------------------------------------------------------------
        # Controlla la risposta data dall'utente.
        #--------------------------------------------------------------
        if [ ${#REPLY} = 0 ]
        then
            #----------------------------------------------------------
            # La risposta è nulla, così si interrompe l'inserimento.
            #----------------------------------------------------------
            exit
        fi
        #--------------------------------------------------------------
        # Finalmente viene creato l'utente.
        #--------------------------------------------------------------
        NUOVO_UTENTE=$REPLY
        /usr/sbin/adduser $NUOVO_UTENTE
        #--------------------------------------------------------------
        # Viene definita la password.
        #--------------------------------------------------------------
        while [ 0 ]                                           # FOREVER
        do
            if /usr/bin/passwd $NUOVO_UTENTE
            then
                #------------------------------------------------------
                # La password è stata inserita correttamente.
                #------------------------------------------------------
                break
            else
                #------------------------------------------------------
                # Meglio ripetere l'operazione.
                #------------------------------------------------------
                continue
            fi
        done
    else
        #--------------------------------------------------------------
        # L'operazione non è consentita.
        #--------------------------------------------------------------
        echo "L'operazione richiesta non è consentita!"
    fi
#======================================================================

Lo script deve essere accessibile in tutti i modi solo all'utente root e in nessun modo agli altri utenti (07008).

L'esecuzione di adduser dipende quindi dalla presenza del file /etc/script/data/AGGIUNGI.OK. In questo modo è possibile regolare semplicemente l'accessibilità a questa funzione.

Per utilizzare in pratica questo sistema, basta identificarsi come l'utente AGGIUNGI in fase di accesso.

350.4   Sincronizzazione di file di configurazione senza NIS

Un laboratorio potrebbe essere organizzato in modo da centralizzare le directory personali degli studenti in un solo file system di rete (di solito NFS), allo scopo di consentire a ogni studente di utilizzare qualunque elaboratore. In generale, per ottenere questo risultato c'è bisogno di centralizzare anche il sistema di autenticazione, normalmente attraverso un servizio NIS. Tuttavia, questa ultima necessità può diventare eccessivamente onerosa per l'amministratore.

Di per sé, l'uso di un file system di rete e del NIS, mette tutto il sistema in una condizione di estrema debolezza rispetto alla possibilità di un'aggressione esterna. Pertanto, si vuole proporre qui un metodo alternativo al NIS, altrettanto debole, ma più semplice da realizzare.

Figura 350.1. Schema semplificato di una rete per un laboratorio, in cui si condividono le directory personali degli utenti, ma non si usa il NIS.

.------.    .------.    .------.    .------.    .------.    .------.
| nodo |    | nodo |    | nodo |    | nodo |    | nodo |    | nodo | B
`------'    `------'    `------'    `------'    `------'    `------'
    |           |           |           |           |           |
 - -*-----------*-----------*-----*-----*-----------*-----------*---- - - -
rete locale del laboratorio       |
                                  |
                     .--------------------------.
                     | Elaboratore contenente i |
                     | servizi e le directory   | A
                     | personali che i nodi     |
                     | normali condividono.     |
                     `--------------------------'

Osservando la figura 350.1, l'elaboratore «A» deve consentire l'accesso alla directory /home/, attraverso il protocollo NFS, mentre gli elaboratori «B» montano il file system di rete nella stessa directory, che per loro sarebbe vuota.

A questo punto, l'aggiunta di un utente dovrebbe passare per l'elaboratore «A», attraverso la procedura normale, cosa che comporta la modifica dei file /etc/passwd e /etc/group (salvo l'uso delle password shadow, che in questo caso non hanno una ragione valida per essere utilizzate), inoltre, genera le directory personali che normalmente si collocano al di sotto di /home/.

Quando gli elaboratori «B» montano la directory /home/, si trovano di fronte alla stessa situazione dell'elaboratore «A», per cui, per consentire l'accesso agli studenti da questi nodi, basterebbe ricopiare i file /etc/passwd e /etc/group. Per farlo in modo automatico, si potrebbe usare Rsync (capitolo 171), predisposto in modo da non dover digitare manualmente delle parole d'ordine, ogni volta che si aggiorna un nodo di tipo «B».

Per usare Rsync in modo autonomo, senza l'ausilio di alcuna shell remota, bisogna configurare tutti i nodi «B» nel modo elencato di seguito.

  1. È necessario verificare che il file /etc/services contempli il servizio RSYNC, contenendo le righe seguenti:

    rsync           873/tcp                         # rsync
    rsync           873/udp                         # rsync
  2. È necessario aggiornare il file /etc/inetd.conf, in modo da avviare rsync come demone, quando viene interpellata la porta del servizio corrispondente:

    rsync   stream  tcp     nowait  root    /usr/bin/rsync  rsyncd --daemon

    Naturalmente occorre riavviare il supervisore dei servizi di rete (inetd), in modo che venga acquisita la modifica fatta in questo file di configurazione.

  3. Si deve preparare il file di configurazione di Rsync, per il suo utilizzo in qualità di demone. Il file in questione dovrebbe essere /etc/rsyncd.conf, ma in caso di dubbio, si può usare l'opzione --config (in questo caso, la riga è spezzata in due per motivi tipografici):

    rsync   stream  tcp     nowait  root    /usr/bin/rsync  (segue)
      rsyncd --daemon --file=/etc/rsyncd.conf

    Il file in questione deve contenere la dichiarazione di un modulo adatto per questo scopo:

    [utenze]
        uid = root
        gid = root
        path = /etc
        read only = false
        auth users = root
        strict modes = false
        secrets file = /etc/rsyncd.secrets
        comment = Esportazione delle utenze attraverso Rsync           
  4. Nel file di configurazione si vede la dichiarazione di un file di «segreti», che in pratica contiene le parole d'ordine in chiaro degli utenti che possono utilizzare tale servizio. In questo caso, si tratta esclusivamente dell'utente root, per cui il file /etc/rsyncd.secrets potrebbe contenere la riga seguente:

    root:supersegretissimo

    La parola d'ordine è in chiaro, per cui sarebbe bene che il file fosse accessibile esclusivamente all'amministratore, utilizzando dei permessi 06008. In particolare, nella configurazione è stata specificata la direttiva strict modes = false in modo da evitare che il demone Rsync possa opporsi all'accesso nel caso i permessi non siano esattamente così. Eventualmente, se si preferisce si può abilitare questo controllo: strict modes = true.

A questo punto, dal lato dei nodi «B» è tutto pronto; basta solo preparare uno script opportuno nell'elaboratore «A», per automatizzare l'operazione:

#! /bin/sh

RSYNC_PASSWORD=supersegretissimo
export RSYNC_PASSWORD

rsync -zv /etc/passwd root@192.168.1.100::utenze
rsync -zv /etc/group root@192.168.1.100::utenze

rsync -zv /etc/passwd root@192.168.1.101::utenze
rsync -zv /etc/group root@192.168.1.101::utenze

rsync -zv /etc/passwd root@192.168.1.102::utenze
rsync -zv /etc/group root@192.168.1.102::utenze

#...

Evidentemente si suppone che i vari nodi «B» abbiano gli indirizzi IP 192.168.1.1*. Naturalmente, se è disponibile il servizio DNS si potevano usare dei nomi al posto degli indirizzi.

Dal momento che questo tipo di approccio non è esente da incidenti, prima di organizzare un sistema di sincronizzazione occorre essere sempre sicuri di disporre di dischetti di emergenza con cui poter avviare gli elaboratori «B», nel caso i file /etc/passwd e /etc/group dovessero risultare danneggiati in qualche modo. Pertanto, tali dischetti di emergenza devono disporre di un sistema autonomo, in quanto non basterebbe un kernel che monta il file system principale che contiene gli stessi file danneggiati.

Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome accorgimenti_per_usare_gnu_linux_nella_didattica_di_massa.html

[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]