Questa sezione del documento descrive l'architettura della rete e i servizi messi a disposizione dalla installazione di Skolelinux.
La figura rappresenta uno schema della topologia di rete. La configurazione predefinita di una rete Skolelinux presuppone un (e solo uno) server principale, e permette l'inclusione di normali workstation e server LTSP (con thin-client associati e/o workstation senza disco). Il numero delle workstation può essere più o meno grande (da nessuna a molte). Lo stesso vale per i server LTSP, ognuno dei quali ha una propria rete separata in modo tale che il traffico tra i client e il server LTSP non influenzi il resto dei servizi di rete. LTSP è spiegato in dettaglio nel capitolo del relativo HowTo.
La ragione per cui può essere presente un solo server principale in ogni rete di scuola è che questo server fornisce il servizio DHCP e può esserci una sola macchina che lo fa in ogni rete. È possibile trasferire i servizi dal server principale a altre macchine, impostando il servizio su un'altra macchina e modificando la configurazione del DNS di conseguenza, in modo che l'alias del DNS per quel servizio punti alla macchina giusta.
Per semplificare la configurazione standard di Skolelinux, la connessione Internet viene eseguita su un router separato, detto anche gateway. Vedere il capitolo sul router Internet per maggiori informazioni su come configurare un gateway se non è possibile configurarne uno esistente.
DHCP nel server Tjener gestisce la rete 10.0.0.0/8, fornendo tramite PXE-Boot un menu syslinux dove si può scegliere di installare un nuovo server/workstation, avviare un thin-client o una workstation senza dischi, eseguire memtest o avviare dall'hard disk locale.
Questo è stato progettato per essere modificato; per i dettagli, vedere il capitolo del relativo HowTo.
Il DHCP nei server LTSP è usato solo per una rete dedicata sulla seconda interfaccia. (192.168.0.0/24 e 192.168.1.0/24 sono le opzioni preconfigurate) e raramente occorre cambiarla.
La configurazione di tutte le sottoreti è archiviata in LDAP.
Una rete Skolelinux ha bisogno di un solo server principale (chiamato anche "tjener" che è la traduzione norvegese di "server") che ha in modo predefinito l'indirizzo IP 10.0.2.2 e che è installato selezionando il profilo "Main Server". È possibile (ma non necessario) selezionare e installare anche i profili LTSP Server e workstation in aggiunta al profilo per il server principale.
Con l'eccezione del controllo dei thin-client, tutti i servizi sono inizialmente configurati su un computer centrale (il server principale). Per ragioni di prestazioni, i server LTSP dovrebbero essere macchine diverse dal server principale (anche se è possibile installare il server principale e i server LTSP sulla stessa macchina). Tutti i servizi hanno un nome-DNS dedicato e vengono forniti solamente via IPv4. I nomi DNS rendono facile il trasferimento di servizi dal server principale ad altre macchine, semplicemente fermando il servizio sul server principale e cambiando la configurazione DNS in modo che punti alla nuova posizione del servizio (che naturalmente dovrebbe essere prima installato sulla macchina scelta).
Per ragioni di sicurezza tutte le connessioni che trasmettono password sulla rete sono cifrate e perciò nessuna password è inviata nella rete come testo in chiaro.
Nella tabella sottostante sono elencati i servizi che sono configurati in modo predefinito in una rete Skolelinux con il nome DNS di ogni servizio. Tutti i file di configurazione si riferiranno, se possibile, al servizio attraverso il nome DNS (senza il nome del dominio), così che le scuole possano cambiare dominio (se hanno un proprio dominio DNS) o indirizzo IP facilmente.
Tabella dei servizi | ||
Descrizione del servizio |
Nome comune |
Nome DNS del servizio |
Log centralizzato |
rsyslog |
syslog |
Servizio dei nomi di dominio |
DNS (BIND) |
domain |
Configurazione automatica della rete per le macchine |
DHCP |
bootps |
Sincronizzazione dell'orologio |
NTP |
ntp |
Directory home via Network File System |
SMB / NFS |
homes |
Sistema di posta elettronica |
IMAP (Dovecot) |
postoffice |
Servizio di directory |
OpenLDAP |
ldap |
Amministrazione degli utenti |
GOsa² |
--- |
Server web |
Apache/PHP |
www |
Backup centrale |
sl-backup, slbackup-php |
backup |
Cache web |
Proxy (Squid) |
webcache |
Stampa |
CUPS |
ipp |
Login remoto sicuro |
OpenSSH |
ssh |
Configurazione automatica |
CFEngine |
cfengine |
LTSP Server |
LTSP |
ltsp |
Controllo delle macchine e dei servizi con segnalazione degli errori, più lo stato e cronologia su web. Segnalazione degli errori attraverso la posta elettronica |
Munin, Icinga e Sitesummary |
sitesummary |
Ogni utente archivia i suoi file personali nella sua directory home messa a disposizione dal server. Le cartelle home sono disponibili da tutte le macchine dando la possibilità di accedere agli stessi file indipendentemente dalla macchina da cui ci si collega. Il server è indipendente dal sistema operativo e utilizza NFS per i client Unix e SMB2/SMB3 per gli altri client.
In modo predefinito la posta elettronica è impostata solo per la consegna in locale (cioè all'interno della scuola), sebbene la spedizione di e-mail verso Internet può essere configurata se la scuola ha una connessione Internet permanente. I client sono predisposti per spedire la posta al server (usando "smarthost"), e gli utenti possono accedere alle loro email attraverso IMAP.
Tutti i servizi sono accessibili usando gli stessi nome utente e password in quanto il database di autenticazione e autorizzazione è centralizzato.
Per incrementare le prestazioni sui siti più frequentati è usato un proxy web (Squid) che archivia i file localmente. Insieme con il blocco del traffico nel router ciò permette il controllo dell'accesso a Internet per le singole macchine.
La configurazione di rete dei client è fatta automaticamente con l'uso di DHCP.Tutti i tipi di client possono essere connessi alla sottorete privata 10.0.0.0/8 e ricevere indirizzi IP corrispondenti, mentre i client LTSP sono connessi al corrispondente server LTSP con la sottorete separata 192.168.0.0/24 (questo assicura che il traffico di rete dei client LTSP non interferisca con il resto dei servizi di rete).
Il servizio centralizzato di log è configurato in modo che tutte le macchine mandino i loro messaggi di syslog al server. Il servizio syslog è predisposto in modo da accettare solamente i messaggi provenienti dalla rete locale.
In modo predefinito il server DNS è configurato con un dominio solamente per uso interno (*.intern) fino a che non viene impostato un dominio DNS reale ("esterno"). Il server DNS è configurato come un server DNS con cache in modo che tutte le macchine della rete possano usarlo come server DNS principale.
Allievi e insegnanti hanno la possibilità di pubblicare pagine web. Il server web dispone di meccanismi per autenticare gli utenti e limitare l'accesso a singole pagine e sottodirectory a determinati utenti e gruppi. Gli utenti avranno la possibilità di creare pagine web dinamiche, dato che c'è la possibilità di programmare dal lato server.
Le informazioni sugli utenti e sulle macchine possono essere modificate centralmente e rese automaticamente accessibili a tutte le macchine della rete. A questo scopo è configurato un server di directory centralizzato. La directory archivierà le informazioni su utenti, gruppi di utenti, macchine e gruppi di macchine. Per evitare confusioni nell'utente, non ci sarà differenza tra gruppi per i file e gruppi di rete. Questo implica che i gruppi di macchine che formeranno i gruppi di rete useranno lo stesso spazio dei nomi dei gruppi di utenti.
L'amministrazione dei servizi e degli utenti avverrà principalmente via web e seguirà gli standard comuni, funzionando bene nei browser che sono inclusi in Skolelinux. La delega di alcuni compiti a singoli utenti o gruppi di utenti sarà resa possibile attraverso i sistemi di amministrazione.
Per evitare alcuni problemi con NFS e rendere più semplice il debug dei problemi, l'orario deve essere sincronizzato sulle diverse macchine. Per questo il server Skolelinux è configurato come server Network Time Protocol (NTP) locale e tutte le macchine e i client sono impostati per sincronizzare il loro orologio con quello del server. Il server a sua volta dovrebbe sincronizzare il proprio orologio in Internet, così da assicurare che l'intera rete abbia l'ora esatta.
Le stampanti vengono collegate dove più comodo, direttamente alla rete principale o ad un server, workstation o server LTSP. L'accesso alle stampanti può essere controllato per i singoli utenti in base ai gruppi ai quali appartengono e realizzato usando il controllo delle quote e degli accessi per le stampanti.
Una rete Skolelinux può avere diversi server LTSP che sono installati selezionando il profilo LTSP Server.
I server LTSP sono configurati per ricevere il syslog dai thin-client e workstation e inoltrare questi messaggi al syslog principale.
Attenzione:
Le workstation senza dischi usano programmi installati nel server.
Il filesystem di root dei client viene realizzato usando NFS. Dopo ogni
modifica al server LTSP l'immagine relativa deve essere rigenerata;
eseguire debian-edu-ltsp-install --diskless_workstation
yes
sul server LTSP.
La configurazione dei thin-client permette a un PC di funzionare come un terminale (X). Questo significa che la macchina si avvia direttamente dal server utilizzando PXE senza usare il disco fisso locale. Il setup del thin client ora usa X2Go perché LTSP ha abbandonato il supporto.
I thin-client sono un modo ottimo per usare ancora macchine molto vecchie (per lo più a 32 bit) in quanto tutti i programmi girano sul server LTSP. Questo funziona come segue: il servizio usa DHCP e TFTP per connettersi alla rete e si inizializza dalla rete stessa. In seguito il file system è montato usando NFS dal server LTSP e da ultimo parte X2Go client.
Le workstation senza dischi eseguono tutto il software nel PC senza avere installato localmente alcun sistema operativo. Questo vuol dire che le macchine si avviano direttamente via PXE senza eseguire alcun software installato su un disco fisso locale.
Le workstation senza dischi sono un modo eccellente di utilizzare hardware potente con lo stesso basso costo di manutenzione dei thin-client. Il software è amministrato e mantenuto sul server senza la necessità di installare alcun software sui client. Anche le directory home e le configurazioni del sistema sono archiviate sul server.
Tutte le macchine Linux che sono installate usando l'installatore di
Skolelinux saranno amministrabili da un computer centrale, probabilmente il
server. Sarà possibile fare il login su tutte le macchine via SSH e avere
il pieno accesso alle macchine. Come root si deve eseguire prima
kinit
per avere Kerberos TGT.
Tutte le informazioni degli utenti sono in una directory LDAP. Le modifiche degli utenti sono fatte in questo database che è usato dai client per l'autenticazione degli utenti.
Attualmente ci sono due tipi di supporti di installazione: netinst e BD. Entrambe le immagini possono essere avviate anche da penna USB.
L'obiettivo è quello di essere in grado di installare una sola volta un server da un qualsiasi tipo di dispositivo per poi installare tutti gli altri client dalla rete mediante l'avvio di rete.
Solo l'immagine netinstall ha bisogno di accedere a Internet durante l'installazione.
L'installazione non dovrebbe fare alcuna domanda, con l'eccezione della lingua desiderata, localizzazione, tastiera e del profilo della macchina (server principale, workstation, server LTSP). Tutte le altre configurazioni saranno impostate automaticamente con parametri ragionevoli che l'amministratore di sistema può eventualmente cambiare da una postazione centralizzata una volta terminata l'installazione.
Ad ogni account utente Skolelinux è assegnata una parte del file system sul file server. Questa parte (la directory home) contiene i file di configurazione, i documenti, le email e le pagine web dell'utente. Alcuni di questi file dovrebbero essere configurati in sola lettura per gli altri utenti del sistema, altri leggibili da tutti via Internet, altri ancora dovrebbero essere accessibili solo all'utente stesso.
Per essere sicuri che tutti i dischi usati per le directory dell'utente e
per le directory condivise abbiano un nome unico per tutti i computer
durante l'installazione, possono essere montati come
/skole/host/directory/
. Inizialmente viene
creata una sola directory sul file server:
/skole/tjener/home0/
in cui vengono messi
tutti gli account utente. Altre directory possono essere create quando è
necessario, per adattarsi a gruppi particolari di utenti o particolari
esigenze di utilizzo.
Per consentire l'accesso ai file condivisi con il normale sistema di permessi UNIX, gli utenti devono essere inseriti in gruppi condivisi supplementari (come "studenti"), oltre al proprio gruppo primario personale di cui fanno parte in modo predefinito. Se gli utenti hanno una umask appropriata per creare nuovi elementi accessibili al gruppo (002 o 007) e le directory su cui lavorano hanno il bit setgid impostato per assicurare che i file ereditino il gruppo proprietario corretto, il risultato è una condivisione di file controllata tra i membri di un gruppo.
Le impostazioni iniziali di accesso per i nuovi file creati dipendono dalla
politica usata. La umask predefinita di Debian è 022 (che non permetterebbe
l'accesso di gruppo come descritto sopra), quella di Debian Edu, invece usa
002, che significa che i file sono creati con possibilità di lettura per
tutti, con la possibilità di rimuoverla in seguito con un'azione specifica
dell'utente. Ciò può essere in alternativa cambiato (modificando
/etc/pam.d/common-session
) con una umask
007, che significa che la possibilità di lettura è inizialmente impedita, ed
è necessaria un'azione dell'utente per renderla accessibile. Il primo metodo
incoraggia la condivisione della conoscenza e rende il sistema più
trasparente, il secondo metodo diminuisce il rischio della diffusione non
voluta di informazioni sensibili. Il problema con la prima soluzione è che
non è evidente per l'utente che il materiale che crea sarà accessibile a
tutti. Può accorgersene solo ispezionando le directory degli altri utenti e
vedendo che tutti i file sono leggibili. Il problema con la seconda
soluzione è che sono pochi gli utenti che sanno rendere accessibile in
lettura i propri file e se questi non contengono informazioni sensibili il
loro contenuto potrebbe essere utile per gli utenti che vogliono imparare a
risolvere problemi che già altri hanno risolto (in genere problemi di
configurazione).