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.

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 SMB per client Windows e Macintosh.

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, mailing-list 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 e delle mailing-list.

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 via NTP con macchine 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 (chiamati anche server thin-client nelle versioni precedenti a Stretch), 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:

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 usato è il Linux Terminal Server Project (LTSP).

I thin-client sono un modo ottimo per usare macchine deboli e obsolete 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 NDB dal server LTSP e da ultimo parte il server X Window. Il display manager (LDM) si connette al server LTSP via SSH con X-forwarding. In questo modo tutti i dati sono cifrati attraverso la rete.

Sono equivalenti al termine workstation senza dischi anche stateless workstation, lowfat client o half-thick client. Per motivi di chiarezza questo manuale usa sempre il termine "workstation senza dischi".

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 dal disco fisso dei server senza eseguire alcun software installato su un disco fisso locale.

Le workstation senza dischi sono un modo eccellente di utilizzare hardware più nuovo 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.

Il termine "client di rete" è usato in questo manuale per riferirsi ai thin-client, alle workstation senza dischi e a tutti i computer che hanno come sistema operativo MacOS o Windows.

Currently there are two kinds of installation media images: netinst and BD. Both images can also be booted from USB sticks.

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 (es. norvegese bokmal, nynorsk, sami) e del profilo della macchina (server, 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 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).

amd64 and i386 are the names of two Debian architectures for x86 CPUs, both are or have been build by AMD, Intel and other manufacturers. amd64 is a 64-bit architecture and i386 is a 32-bit architecture. New installations today should be done using amd64. i386 should only be used for old hardware.

The netinst iso image can be used for installation from CD/DVD and USB flash drives and is available for two Debian architectures: amd64 or i386. As the name implies, internet access is required for the installation.

Once Buster has been released these images will be available for download from:

This ISO image is approximately 5 GB large and can be used for installation of amd64 or i386 machines, also without access to the Internet. Like the netinst image it can be installed on USB flash drives or disk media of sufficient size.

Once Buster has been released these images will be available for download from:

Sources are available from the Debian archive at the usual locations, several media are linked on http://get.debian.org/cdimage/release/current/source/

Debian Edu come progetto internazionale ha scelto di usare Xfce come desktop predefinito; vedere sotto come impostarne uno diverso.

Menu di avvio dell'installatore su hardware a 64-bit

Selezionare Graphical install per usare l'installatore GTK in cui si può usare il mouse.

Install uses text mode.

Advanced options > porta a un sotto menu con maggiori opzioni da scegliere

Help dà alcuni suggerimenti sull'utilizzo dell'installazione; vedere gli screenshot sotto.

Back.. riporta al menu principale.

Graphical expert install dà accesso a tutte le domande disponibili in modalità grafica.

Graphical rescue mode permette di utilizzare questo supporto di installazione come disco di ripristino per le attività di emergenza.

Graphical automated install ha bisogno di un file di preconfigurazione.

Expert install dà accesso a tutte le domande disponibili in modalità testuale.

Rescue mode modo testo; permette di utilizzare questo supporto di installazione come disco di ripristino per le attività di emergenza.

Automated install modo testo; ha bisogno di un file di preconfigurazione.

Schermate di aiuto

Questa schermata di aiuto si spiega da sé e con i tasti <F> sulla tastiera permette di ottenere una guida più dettagliata sugli argomenti descritti.

Aggiungere o modificare i parametri di avvio per le installazioni

In entrambi i casi le opzioni di avvio possono essere modificate premendo il tasto Tab nel menu di avvio, la schermata mostra la riga di comando per l'installazione grafica.

Ricordarsi i requisiti di sistema e assicurarsi di avere almeno due schede di rete (NIC) se si si desidera installare un server LTSP.

Dal rilascio di Squeeze è possibile copiare direttamente l'immagine .iso su una penna USB e avviare da questa. Basta eseguire un comando come questo adattando i nomi dei file e del dispositivo alle proprie necessità:

sudo dd if=debian-edu-amd64-XXX.iso of=/dev/sdX bs=1024

A seconda dell'immagine scelta, la penna USB si comporterà esattamente come un CD o Blu-ray disc.

Per questo metodo di installazione è necessario avere un server principale in esecuzione. Quando i client si avviano dalla rete principale, viene visualizzato un nuovo menu PXE con opzioni perla selezione dell'installatore e dell'avvio. Se l'installazione PXE fallisce con un messaggio di errore che indica che un file XXX.bin è mancante, allora molto probabilmente la scheda di rete del client richiede un firmware non libero. In questo caso deve essere modificato l'initrd dell'installatore Debian. Questo può essere fatto con il comando: /usr/share/debian-edu-config/tools/pxe-addfirmware sul server.

Così appare il menu PXE solo con il profilo Main-Server:

Così appare il menu PXE con i profili Main Server e LTSP Server:

Per installare un altro ambiente desktop al posto di quello di default, premere TAB e modificare le opzioni di avvio del kernel (come spiegato sopra).

Questa configurazione permette anche di avviare workstation senza dischi e thin-client sulla rete principale. A differenza delle workstation, le workstation senza dischi non devono essere aggiunte a LDAP con GOsa² a meno che si voglia forzare il nome dell'host.

Maggiori informazioni sui client della rete possono essere trovati nella sezione HowTo per i client di rete.

d-i    pkgsel/include string miei-pacchetti-extra

Creare una versione personalizzata del CD, DVD o Blu-ray è possibile abbastanza facilmente, usando l'installatore Debian, che ha un progetto modulare e altre interessanti caratteristiche. L'uso di preconfigurazione permette di definire le risposte alle domande normalmente richieste.

Quello che è necessario è creare un file di preconfigurazione con le risposte personalizzate (tutto questo è descritto nell'appendice del manuale dell'installatore Debian) e rimasterizzare il CD/DVD.

Ci sono diversi servizi attivi sul server principale che possono essere gestiti attraverso l'interfaccia web. Di seguito viene descritto ogni servizio.

Dopo che ci si è collegati a GOsa² si vedrà la pagina iniziale di GOsa².

Successivamente, è possibile scegliere un'azione nel menu o fare clic su una delle icone della pagina iniziale. Per la navigazione, si consiglia di utilizzare il menu a sinistra dello schermo, in quanto questo rimarrà visibile su tutte le pagine di amministrazione di GOsa².

In Debian Edu le informazioni sugli account, i gruppi e il sistema sono archiviate in una directory LDAP. Questi dati non sono usati solo dal server principale, ma anche dalle (diskless) workstation, dai server LTSP e dalle macchine Windows nella rete. Con LDAP le informazioni degli studenti, insegnanti, etc. devono essere inserite una sola volta. Dopo aver fornito le informazioni in LDAP, le stesse saranno disponibili su tutti i sistemi della rete Skolelinux.

Gosa² è uno strumento di amministrazione che usa LDAP per memorizzare le informazioni e fornire una struttura gerarchica di dipartimenti.Per ogni "dipartimento" è possibile aggiungere account utenti, gruppi, sistemi, gruppi di rete, ecc. A seconda della struttura della vostra istituzione, è possibile utilizzare la struttura del dipartimento in Gosa²/LDAP per trasferire la struttura organizzativa della scuola in un albero dati LDAP del server principale di Debian Edu.

Un'installazione predefinita del server principale di Debian Edu offre attualmente due "dipartimenti": Teachers e Students, oltre il livello base dell'albero LDAP. Gli account degli studenti sono destinati ad essere aggiunti al dipartimento "Students", gli insegnanti al dipartimento "Teachers", i sistemi (server, postazioni di lavoro Skolelinux, macchine Windows, etc.) sono attualmente aggiunti al livello di base. Questa struttura può essere personalizzata in base alle proprie esigenze. (Si può trovare un esempio su come creare utenti per gruppi di anni, con home directory comuni per ogni gruppo nella sezione HowTo/AdvancedAdministration di questo manuale).

A seconda dell'azione su cui si desidera lavorare (gestire utenti, gestire gruppi, gestire sistemi, etc.) Gosa² presenta una schermata diversa per il dipartimento selezionato (o per il livello di base).

Accanto alla navigazione ad albero c'è il menu "Actions". Spostare il mouse su questa voce e un sottomenu appare sullo schermo, scegliere "Create" qui, e poi "User". Ci sarà una procedura guidata che aiuterà nella creazione dell'utente.

Dopo aver creato l'utente (per ora non è necessario personalizzare i campi che la procedura guidata ha lasciato vuoti), fare clic sul pulsante "Ok" in basso a destra.

Come ultimo passo GOsa² chiederà una password per il nuovo utente. Digitare la password due volte, quindi fare clic su "Set password" in basso a destra. Alcuni caratteri non sono permessi nella password.

Se tutto è andato bene, ora è possibile vedere il nuovo utente nella tabella degli utenti. Ora si dovrebbe essere in grado di accedere con quel nome utente su qualsiasi macchina Skolelinux all'interno della rete.

Per modificare o cancellare un utente si usa GOsa² per sfogliare l'elenco degli utenti nel proprio sistema. In alto a sinistra dello schermo, si trova il riquadro "Filter", uno strumento di ricerca fornito da GOsa². Se non si conosce esattamente dove si trova l'account nell'albero, occorre spostarsi nel livello di base dell'albero di GOsa²/LDAP e cercare con l'opzione chiamata: "[x] Cerca in subtrees".

Quando si usa il riquadro "Filter", i risultati appariranno immediatamente in mezzo al testo nell'elenco della tabella. Ogni riga rappresenta un account utente e gli elementi più a destra di ogni riga sono piccole icone che forniscono le azioni necessarie: modificare utente, bloccare l'account, impostare la password e rimuovere l'utente.

Verrà mostrata una nuova pagina in cui si possono modificare direttamente le informazioni dell'utente come cambiare la password dell'utente o modificare la lista dei gruppi ai quali appartiene.

Gli studenti possono cambiare la propria password accedendo a GOsa² con i loro nomi utente. Per facilitare l'accesso a GOsa², è presente un'icona denominata Gosa nel desktop e nel menu di sistema (o Impostazioni di sistema). La versione di GOsa² per uno studente che vi accede è davvero minimale permettendo solo l'accesso ai propri dati di account e alla possibilità di cambiare la password.

Gli insegnanti hanno privilegi speciali in GOsa². Essi hanno una vista privilegiata di GOsa² e possono cambiare la password per tutti gli studenti. Questo può essere molto utile in classe.

Per configurare una nuova password per l'utente

Attenzione alla sicurezza per le password facili da indovinare!

È possibile creare una grande quantità di utenti con GOsa² utilizzando un file CSV, che può essere creato con un buon foglio di calcolo (per esempio localc). Occorre inserire almeno i seguenti campi: uid, cognome (sn), nome (givenName) e password. Assicurarsi che non ci siano voci duplicate nel campo uid. Occorre controllare anche di non duplicare uid esistenti in LDAP (questi possono essere ottenuti eseguendo getent passwd | grep tjener/home | cut -d":" -f1 da terminale).

Qui ci sono le indicazioni su come creare un file CSV (GOsa² è abbastanza intollerante con questi file):

Le operazioni per l'importazione di massa sono:

È una buona idea fare qualche test prima, meglio con un file CSV che contiene pochi utenti fittizi che potranno essere cancellati più tardi.

Lo stesso vale per il modulo di gestione password, che permette di resettare molte password utilizzando un file CSV o per rigenerare nuove password per gli utenti appartenenti ad uno speciale sottoalbero LDAP.

# Elencare la mappatura esistente tra i gruppi UNIX e Windows.
net groupmap list

# Aggiungere i propri gruppi nuovi o mancanti:
net groupmap add unixgroup=NUOVO_GRUPPO type=domain ntgroup="NUOVO_GRUPPO"\
                 comment="DESCRIZIONE DEL NUOVO GRUPPO"

Cercare e cancellare le macchine è simile a cercare e cancellare utenti e la procedura qui non viene ripetuta.

Dopo aver aggiunto una macchina all'albero LDAP usando GOsa², si può modificarne le proprietà usando la funzione di ricerca e cliccando sulla macchina desiderata (come per gli utenti).

Il formato di queste voci di sistema è simile a quello che già è stato visto per modificare le voci degli utenti, ma i campi significano cose diverse in questo contesto.

Per esempio, quando si aggiunge una macchina a un NetGroup non si modificano i permessi di accesso ai file o di esecuzione di comandi per quella macchina o per gli utenti che si collegano da essa, ma si limitano invece i servizi che tale macchine può usare sul server principale.

L'installazione predefinita mette a disposizione i seguenti NetGroup

Al momento la funzionalità NetGroup è usata per

Un'altra importante parte della configurazione delle macchine è la casella "Samba host" (nella sezione "Host information"). Se si progetta di aggiungere macchine Windows al dominio Samba di Skolelinux, occorre aggiungere l'host Windows all'albero LDAP e attivare questa casella per permettere alla macchina di collegarsi al dominio. Per maggiori informazioni su come aggiungere macchine Windows alla rete Skolelinux vedere la sezione HowTo/NetworkClients di questo manuale.

Eseguire cron-apt come è stato descritto sopra è un buon modo per sapere che per un pacchetto è disponibile un aggiornamento di sicurezza. Un altro modo per essere informati sugli aggiornamenti di sicurezza è l'iscrizione alla mailing-list Debian security-announce, che ha il vantaggio di spiegare cosa l'aggiornamento riguardi. Il lato negativo (confrontato con cron-apt) è che vengono date anche informazioni su pacchetti che non sono stati installati.

Il monitoraggio di sistema di Munin è disponibile su https://www/munin/. Il sistema permette di verificare graficamente lo stato del sistema giornalmente, settimanalmente, mensilmente e annualmente, e permette all'amministratore del sistema di avere un aiuto per individuare i colli di bottiglia e per l'origine dei problemi del sistema.

L'elenco delle macchine controllate da Munin è generato automaticamente sulla base dell'elenco degli host riportato da sitesummary. Tutti gli host che hanno installato il pacchetto munin-node sono controllati da Munin. Normalmente bisogna aspettare un giorno dall'installazione di una macchina prima che parta il monitoraggio di Munin a causa dell'ordine in cui vengono eseguiti i compiti di cron. Per velocizzare il processo occorre eseguire sitesummary-update-munin come root sul server di sitesummary (normalmente il server principale). Questo aggiornerà il file /etc/munin/munin.conf.

L'insieme delle misurazioni raccolte viene generato automaticamente su ciascuna macchina usando il programma munin-node-configure, che esplora i plugin disponibili da /usr/share/munin/plugins/ e crea i collegamenti simbolici rilevanti in /etc/munin/plugins/.

Maggiori informazioni su Munin sono disponibili a http://munin-monitoring.org/.

Il monitoraggio di sistemi e servizi Icinga è disponibile su https://www/icinga/. L'insieme di macchine e servizi oggetto del monitoraggio viene generato automaticamente usando le informazioni raccolte da sitesummary. Le macchine con il profilo di Main-server e LTSP server hanno un monitoraggio completo, mentre le workstation e thin client hanno un monitoraggio più limitato. Per consentire un controllo completo su una workstation, installare il pacchetto nagios-nrpe-server sulla workstation.

Il nome utente è icingaadmin e la password predefinita è skolelinux. Per ragioni di sicurezza, occorre evitare di usare la stessa password di root. Per cambiare la password occorre eseguire il seguente comando come root:

htpasswd /etc/icinga/htpasswd.users icingaadmin

In modo predefinito Icinga non invia email. Questo può essere cambiato sostituendo notify-by-nothing con host-notify-by-email e notify-by-email nel file /etc/icinga/sitesummary-template-contacts.cfg.

Il file di configurazione di Icinga è /etc/Icinga/sitesummary.cfg. Il cron di sitesummary genera /var/lib/sitesummary/icinga-generated.cfg con la lista delle macchine e dei servizi controllati.

Controlli extra di Icinga possono essere inseriti nel file /var/sitesummary/lib/icinga-generated.cfg.post per includerli nel file prodotto.

Maggiori informazioni sul sistema Icinga sono disponibili al sito http://www.icinga.com/ o nel pacchetto icinga-doc.

Sitesummary è usato per archiviare le informazioni da ogni computer e sottoporle al server centrale. Le informazioni archiviate sono disponibili in /var/lib/sitesummary/entries/. In /usr/lib/sitesummary/ sono disponibili script per generare rapporti.

Un semplice report di sitesummary senza ogni dettaglio è disponibile all'indirizzo https://www/sitesummary/.

Altra documentazione su sitesummary è disponibile all'indirizzo http://wiki.debian.org/DebianEdu/HowTo/SiteSummary

apt update
apt full-upgrade

apt clean

sed -i 's/stretch/buster/g' /etc/apt/sources.list
export LC_ALL=C        # optional (to get English output)
apt update
apt purge atftpd       # needed because tftpd will be installed
apt install libcurl4   # needed to replace libcurl3
apt install apache2    # needed first to avoid additional work later on
apt full-upgrade

cf-agent -I -D installation

apt install debian-edu-artwork-buster

apt purge php7.0*
a2enmod php7.3
a2enconf php7.3-cgi
service apache2 restart

apt purge linux-image-4.9.0-*
apt purge linux-headers-4.9.0-*
apt --purge autoremove

Riavviare: accedi come primo utente e prova

Fare tutte le cose fondamentali come sul server principale, senza fare le cose non necessarie.

Assicurarsi di avere spazio sufficiente su disco. LTSP utilizza Network Block Device (NBD). La dimensione del file immagine NBD è di circa 4 GiB (installazione predefinita). Se l'immagine viene aggiornata, sono necessari altri 4 GiB per un file temporaneo.

Si noti anche che l'architettura LTSP predefinita per Stretch era i386. Vedere sotto come creare un chroot per i PC a 64 bit (amd64).

ltsp-chroot -m -a i386 apt update
ltsp-chroot -m -a i386 apt -y full-upgrade
sed -i 's/stretch/buster/g' /opt/ltsp/i386/etc/apt/sources.list
ltsp-chroot -m -a i386 apt update
ltsp-chroot -m -a i386 apt -y full-upgrade
ltsp-chroot -m -a i386 apt -f install
ltsp-chroot -m -a i386 apt -y full-upgrade

ltsp-chroot -m -a i386 apt --purge autoremove

ltsp-update-kernels
ltsp-update-sshkeys
ltsp-update-image

Per risparmiare spazio su disco, si potrebbe invece utilizzare, ltsp-update-image -n; vedere man ltsp-update-image.

Sui server LTSP la chroot di LTSP dovrebbe essere ricreata. La nuova chroot supporterà di nuovo automaticamente sia i thin-client che le workstation senza dischi. Nota: a partire da Buster, l'arch di chroot LTSP predefinita è quella utilizzata per il lato server.

Cancellare /opt/ltsp/i386 (o /opt/ltsp/amd64, in relazione alla propria configurazione). Se si ha abbastanza spazio nel disco, prendere in considerazione di fare il backup.

Vedere ltsp-build-client --help e ltsp-build-client --extra-help per maggiori informazioni sulle opzioni. Il file /etc/ltsp/ltsp-build-client.conf contiene alcune opzioni utili (commentate).

Eseguire come root ltsp-build-client --arch amd64 per ricreare la chroot.

Sono necessari almeno 20 GiB di spazio supplementare su disco in /opt.

In un sistema installato recentemente proviamo a vedere quali cambiamenti sono stati fatti dall'installazione iniziale:

etckeeper vcs log

Per vedere quali file non sono attualmente tracciati e quali non sono aggiornati:

etckeeper vcs status

Per fare il commit manuale di un file, senza aspettare un'ora:

etckeeper vcs commit -a /etc/resolv.conf

Logical Volume Management (LVM) permette di estendere le partizioni mentre sono montate e in uso. Si può imparare di più su LVM in LVM HowTo.

Per estendere un volume logico manualmente si può semplicemente eseguire il comando lvextend e indicare quanto grande debba diventare. Per esempio, per estendere home0 a 30GB si usa il seguente comando:

lvextend -L30G /dev/vg_system/skole+tjener+home0
resize2fs /dev/vg_system/skole+tjener+home0

Per aggiungere 30G a home0, si deve inserire un '+' (-L+30G)

Main server

/srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs4/home0  gss/krb5i(rw,sync,no_subtree_check)

Workstation

Sui client che dovrebbero spegnersi di notte, usare touch su /etc/shutdown-at-night/shutdown-at-night o aggiungere il nome dell'host (cioè l'output che si ottiene da 'uname -n' nel client) al netgroup "shutdown-at-night-hosts". Per aggiungere host al netgroup in LDAP si può usare lo strumento web GOsa². I client potrebbero avere bisogno di avere wake-on-lan configurato nel BIOS. Ancora, è importante che gli switch e i router usati tra il server wake-on-lan e i client passino pacchetti WOL ai client anche se i client sono spenti. Alcuni switch non riescono a passare i pacchetti ai client che non sono presenti nella tabella ARP sullo switch e questo blocca i pacchetti WOL.

Per abilitare wake-on-lan sul server, aggiungere i client a /etc/shutdown-at-night/clients, con una riga per ogni client, l'indirizzo IP per primo e l'indirizzo MAC (indirizzo ethernet) separati da uno spazio, o creare uno script in /etc/shutdown-at-night/clients-generator per generare l'elenco dei client al volo.

Un esempio di /etc/shutdown-at-night/clients-generator per l'utilizzo con sitesummary:

  #!/bin/sh
  PATH=/usr/sbin:$PATH
  export PATH
  sitesummary-nodes -w

Se si usa il netgroup un'alternativa per l'attivazione di shutdown-at-night sui clients è data da questo script con l'uso degli strumenti di netgroup dal pacchetto ng-utils:

  #!/bin/sh
  PATH=/usr/sbin:$PATH
  export PATH
  netgroup -h shutdown-at-night-hosts

In questo esempio vogliamo creare utenti in gruppi per ogni anno, con home directory comuni per ogni gruppo (home0/2014, home0/2015, etc.). Gli utenti saranno creati importando un file csv.

(come root sul server principale)

mkdir /skole/tjener/home0/2014

(come primo utente in Gosa)

Menu principale: andare in "Directory structure", clic su dipartimento "Students". Il campo "Base" dovrebbe visualizzare "/Students". Dalla casella "Actions" scegliere "Create"/"Department". Inserire i valori per Name (2014) e nel campo Description (studenti iscritti nel 2014), lasciare il campo Base così com'è (dovrebbe essere "/Students"). Salvare facendo clic su "Ok". Ora il nuovo dipartmento (2014) dovrebbe essere visualizzato sotto /Students. Fare clic su di esso.

Scegliere "Groups" dal menu principale; "Actions"/Create/Group. Inserire il nome del gruppo (lcasciare "Base" così com'è, dovrebbe essere /Students/2014) e clic sulla casella di controllo a sinistra di "Samba group". "Ok" per salvarlo.

Scegliere 'users' dal menu principale. Cambiare a "Students" nel campo Base. Si dovrebbe vedere la voce NewStuden', cliccarci sopra. Questo è il modello per gli studenti, non un utente reale. Si dovrebbe creare un modello basato su questo (per poter usare l'importazione da csv per la propria struttura) perciò prestare attenzione a tutte le voci nelle schede Generic POSIX e Samba, magari catturando screenshot per avere informazioni utili per il nuovo modello.

Ora cambiare a /Students/2014 nel campo Base; scegliere Create/Template e cominciare a riempire con i valori desiderati, prima la scheda Generic (aggiungere il nuovo gruppo 2014 anche sotto il Group Membership), poi aggiungere gli account POSIX e Samba.

Scegliere il nuovo modello quando si importa il csv; conviene provarlo con pochi utenti.

Con questo script l'amministratore può creare una cartella in tutte le directory home degli utenti e impostare permessi e proprietà.

Nell'esempio mostrato sotto con il gruppo=teachers e i permessi=2770 un utente può consegnare un compito salvando il file nella cartella "assignments" dove gli insegnanti hanno accesso di scrittura per fare commenti.

 #!/bin/bash
 home_path="/skole/tjener/home0"
 shared_folder="assignments"
 permissions="2770"
 created_dir=0
 for home in $(ls $home_path); do
    if [ ! -d "$home_path/$home/$shared_folder" ]; then
        mkdir $home_path/$home/$shared_folder
        chmod $permissions $home_path/$home/$shared_folder
        #set the right owner and group
        #"username" = "group name" = "folder name"
        user=$home
        group=teachers
        chown $user:$group $home_path/$home/$shared_folder
        ((created_dir+=1))
    else
        echo -e "the folder $home_path/$home/$shared_folder already exists.\n"
    fi
 done
 echo "$created_dir folders have been created"

Quando gli utenti inseriscono un drive USB o un DVD/CDROM dentro una workstation (senza dischi), si attiva una finestra popup che chiede cosa si vuole fare, come in ogni altra normale installazione.

Quando gli utenti inseriscono un componente USB o un DVD / CDROM in un thin client viene mostrata una notifica per pochi secondi. Il supporto è automaticamente montato ed è possibile accedervi nella cartella /media/$user. Questo può essere problematico per utenti non esperti.

È possibile far aprire Dolphin, il gestore di file predefinito di KDE "Plasma", se KDE "Plasma" (o LDXE, se installato insieme a KDE "Plasma") è l'ambiente desktop in uso. Per configurarlo va eseguito /usr/share/debian-edu-config/ltspfs-mounter-kde enable su un server di terminale. (Quando si usa GNOME, le icone dei dispositivi saranno visibili sul desktop permettendo un accesso facilitato.)

In aggiunta lo script seguente può essere usato per creare un collegamento simbolico "media" nella directory home di tutti gli utenti per avere un accesso più facile ai drive USB, ai CDROM / DVD o ad altri supporti connessi ai thin-client. Questo potrebbe essere utile se gli utenti vogliono modificare i loro file nei supporti inseriti.

 #!/bin/bash
 home_path="/skole/tjener/home0"
 shared_folder="media"
 permissions="775"
 created_dir=0;
 for home in $(ls $home_path); do
    if [ ! -d "$home_path/$home/$shared_folder" ]; then
        ln -s /media/$home $home_path/$home/$shared_folder
        ((created_dir+=1))
    else
        echo -e "the folder $home_path/$home/$shared_folder already exists.\n"
    fi
 done
 echo "$created_dir folders has been created"

Se non vengono usati client LTSP una soluzione semplice è quella di creare un nuovo gruppo (per esempio sshusers) e aggiungere una riga al file /etc/ssh/sshd_config della macchina. Solo ai membri del gruppo sshusers sarà permesso di utilizzare ssh nella macchina dappertutto.

La gestione di questo caso con GOsa è abbastanza semplice:

L'installazione predefinita del client LTSP utilizza connessioni ssh al server LTSP. Per questo è necessario un approccio diverso con PAM.

+ : alice jane bob john : ALL
+ : ALL : 10.0.0.0/8 192.168.0.0/24 192.168.1.0/24
- : ALL : ALL
#

Se sono utilizzati solo server LTSP dedicati, la rete 10.0.0.0/8 potrebbe essere disabilitata per il login ssh interno. Nota: qualcuno che collega la sua box alla rete dei client dedicata LTSP avrà accesso ssh ai server LTSP.

Se i client LTSP sono stati collegati alla rete backbone 10.0.0.0/8 (combi server o server con configurazione LTSP cluster) sarebbe ancora più complicato e forse solo una configurazione DHCP sofisticata (in LDAP) con il controllo del vendor-class-identifier insieme a una configurazione PAM appropriata permetterebbe di disabilitare il login ssh interno.

Ogni server LTSP ha due schede di rete ethernet, una è configurata nella sottorete principale 10.0.0.0/8 (condivisa con il server principale) e l'altra che forma una sottorete locale 192.168.0.0/24 (una sottorete separata per ogni server LTSP).

Nella rete principale si riporta un menu complete PXE; la sottorete separata per ogni server LTSP permette solo la selezione tra client senza dischi e thin-client.

Se si usa il menu PXE predefinito, nella rete principale 10.0.0.0/8, una macchina potrebbe partire come workstation senza dischi o thin-client. I client nella sottorete separata 192.168.0.0/24 funzioneranno in modo predefinito come workstation senza dischi se la quantità di RAM è sufficiente. Se tutti i client nella sottorete LTSP dovranno funzionare come thin-client, bisognerà eseguire queste istruzioni.

(1)Open the file /opt/ltsp/amd64/etc/ltsp/update-kernels.conf with an editor
and replace the line
CMDLINE_LINUX_DEFAULT="init=/sbin/init-ltsp quiet"
with
CMDLINE_LINUX_DEFAULT="init=/sbin/init-ltsp LTSP_FATCLIENT=False quiet"
(2)Execute 'ltsp-chroot -a amd64 /usr/share/ltsp/update-kernels'
(3)Execute 'ltsp-update-kernels'
(4)Execute 'ltsp-update-image'

L'opzione di installazione di PXE è disponibile in modo predefinito per chiunque sia in grado di fare l'avvio via PXE di una macchina. Per proteggere con password le opzioni di installazione di PXE, può essere creato un file /var/lib/tftpboot/menupassword.cfg con un contenuto simile a:

MENU PASSWD $4$NDk0OTUzNTQ1NTQ5$7d6KvAlVCJKRKcijtVSPfveuWPM$

L'hash della password deve essere sostituito con un hash MD5 per la password desiderata.

L'installazione di PXE erediterà la lingua, la disposizione della tastiera e le sue impostazioni rifletteranno le impostazioni utilizzate durante l'installazione del server principale, e le altre domande saranno poste durante l'installazione (profilo, partecipazione a popcon, il partizionamento e la password di root). Per evitare queste domande, il file /etc/debian-edu/www/debian-edu-install.dat può essere modificato per fornire risposte preselezionate ai valori di debconf. Alcuni esempi di valori di debconf disponibili sono commentati in /etc/debian-edu/www/debian-edu-install.dat. I cambiamenti fatti saranno persi appena debian-edu-pxeinstall verrà usato per ricreare l'ambiente di installazione di PXE. Per aggiungere i valori di debconf a /etc/debian-edu/www/debian-edu-install.dat durante la ricreazione con debian-edu-pxeinstall, aggiungere il file /etc/debian-edu/www/debian-edu-install.dat.local con i propri valori aggiuntivi per debconf.

Maggiori informazioni sulla modifica dell installazione PXE possono essere trovati nella sezione Installazione.

Per aggiungere un repository personalizzato inserire qualcosa come questo in /etc/debian-edu/www/debian-edu-install.dat.local:

#add the skole projects local repository
d-i     apt-setup/local1/repository string      http://example.org/debian stable main contrib non-free
d-i     apt-setup/local1/comment string         Example Software Repository
d-i     apt-setup/local1/source boolean         true
d-i     apt-setup/local1/key    string          http://example.org/key.asc

ed eseguire poi /usr/sbin/debian-edu-pxeinstall una volta.

Il menu PXE permette l'avvio dalla rete dei client LTSP, dell'installatore e delle altre alternative. Il file /var/lib/tftpboot/pxelinux.cfg/default è usato in modo predefinito se non ci sono altri file in quella directory che corrispondono al client ed è nell'installazione standard configurato per essere un collegamento a /var/lib/tftpboot/debian-edu/default-menu.cfg.

Se si vuole che tutti i client si avviino come workstation senza dischi al posto dell'intero menu PXE, occorre cambiare il collegamento simbolico:

ln -s /var/lib/tftpboot/debian-edu/default-diskless.cfg /var/lib/tftpboot/pxelinux.cfg/default

Se si vuole che tutti i client si avviino come thin-client cambiare il collegamento simbolico così:

ln -s /var/lib/tftpboot/debian-edu/default-thin.cfg /var/lib/tftpboot/pxelinux.cfg/default

Vedere anche la documentazione di PXELINUX su http://syslinux.zytor.com/wiki/index.php/PXELINUX.

Per ragioni di prestazioni e di sicurezza conviene non configurare un server principale come server LTSP.

Per avere ltspserver00 che controlla le workstation senza dischi sulla rete principale (10.0.0.0/8), quando il server principale non è un server combinato, occorre seguire i seguenti passaggi:

 DEFAULT ltsp/amd64/vmlinuz initrd=ltsp/amd64/initrd.img nfsroot=10.0.2.10:/opt/ltsp/amd64 init=/sbin/init-ltsp boot=nfs ro quiet ipappend 2

In alternativa, è possibile utilizzare ldapvi, cercare "next server tjener" e sostituire tjener con ltspserver00.

La rete predefinita per la rete dei client LTSP è 192.168.0.0/24 se una macchina è installata usando il profilo LTSP. Se sono usati molti client LTSP o se diversi server LTSP dovrebbero far funzionare sia i386 che amd64 si potrebbe utilizzare l'ambiente chroot della seconda rete preconfigurata 192.168.1.0/24. Modificare il file /etc/network/interfaces e regolare il settaggio di eth1 di conseguenza. Usare ldapvi o ogni altro editor LDAP per ispezionare la configurazione DNS e DHCP.

Nel caso in cui il server LTSP e la chroot siano a 64 bit-PC è ancora possibile supportare i vecchi sistemi a 32 bit. Almeno 20 GiB di spazio aggiuntivo su disco in /opt sarebbero necessari.

Per configurare specifici client LTSP con particolari caratteristiche, si possono aggiungere le impostazioni in LDAP o modificare il file /opt/ltsp/amd64/etc/lts.conf. Notare che occorre eseguire ltsp-update-image ogni volta che si cambia lts.conf. Non importa aggiornare l'immagine se lts.conf è copiato nella directory /var/lib/tftpboot/ltsp/amd64/.

Raccomandiamo di configurare i client in LDAP (e non modificare direttamente lts.conf, la configurazione via web per LTSP non è disponibile per ora in GOsa², occorre usare un browser LDAP o ldapvi), in quanto ciò rende possibile aggiungere e/o sostituire i server LTSP senza perdere (o dover rifare) la configurazione.

I valori predefiniti in LDAP sono definiti nell'oggetto LDAP cn=ltspConfigDefault,ou=ltsp,dc=skole,dc=skolelinux,dc=no utilizzando l'attributo ltspConfig. Si possono anche aggiungere voci specifiche di host in LDAP.

Eseguire man lts.conf per dare un'occhiata alle opzioni disponibili della configurazione (vedere /usr/share/doc/ltsp/LTSPManual.html per informazioni dettagliate su LTSP).

I valori predefiniti sono definiti in [default]; per configurare un client, occorre indicarlo usando l'indirizzo MAC o l'IP del client come questo: [192.168.0.10].

Esempio: per permettere al thin client ltsp010 di usare una risoluzione 1280x1024, aggiungere qualcosa di simile:

[192.168.0.10]
X_MODE_0 = 1280x1024
X_HORZSYNC = "60-70"
X_VERTREFRESH = "59-62"

da qualche parte sotto alle impostazioni predefinite.

Per forzare l'utilizzo di un specifico xserver su un client LTSP, impostare la variabile XSERVER. Per esempio:

[192.168.0.11]
XSERVER = nvidia

Se un thin client si presenta con uno schermo nero l'uso della profondità di un colore specifico potrebbe aiutare help. Per esempio:

[192.168.0.12]
X_COLOR_DEPTH=16

A secondo di quali cambiamenti sono stati fatti, può essere necessario riavviare il client.

Se si usa l'indirizzo IP in lts.conf si dovrebbe aggiungere l'indirizzo MAC al server DHCP. Altrimenti è necessario usare l'indirizzo MAC del client direttamente nel file lts.conf.

Assicurarsi che LXDE sia installato sul server LTSP; poi aggiungere queste righe sotto [default] in "lts.conf":

LDM_SESSION=LXDE
LDM_FORCE_SESSION=true

Questo strumento precarica l'ambiente desktop predefinito (e i programmi scelti). È utile solo per i client senza disco. La configurazione è specifica del sito, sono richieste anche alcune competenze tecniche

È necessario modificare almeno due file. Le scelte disponibili degli <editor> sono: vi, nano, mcedit.

Se il setup è completo, aggiornare l'immagine NBD con ltsp- update-image e testarlo.

I thin client LTSP usano networked audio to pass audio from the server to the clients.

Le workstation senza dischi LTSP gestiscono l'audio localmente.

Per velocizzare la personalizzazione e il test si può utilizzare un chroot LTSP NFS.

# Switch from NBD --> NFS:
sed -i 's/default ltsp-NBD/default ltsp-NFS' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp
sed -i 's/ontimeout ltsp-NBD/ontimeout ltsp-NFS/' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp
ltsp-update-kernels

# Switch from NFS --> NBD:
ltsp-update-image 
sed -i 's/default ltsp-NFS/default ltsp-NBD' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp
sed -i 's/ontimeout ltsp-NFS/ontimeout ltsp-NBD/' /opt/ltsp/$(dpkg --print-architecture)/boot/pxelinux.cfg/ltsp
ltsp-update-kernels

È utile aggiornare spesso l'ambiente LTSP con i nuovi pacchetti, per assicurarsi che le risoluzioni dei problemi di sicurezza e i miglioramenti siano disponibili nella propria rete. Per l'aggiornamento occorre eseguire questi comandi come utente root su ogni server LTSP:

ltsp-chroot -a amd64  # this does "chroot /opt/ltsp/amd64" and more, ie it also prevents daemons from being started
apt update
apt upgrade
apt full-upgrade
exit
ltsp-update-image

ltsp-chroot -a amd64
## optionally, edit the sources.list:
#editor /etc/apt/sources.list
apt update
apt install $new_package
exit
ltsp-update-image

Skolelinux ha aggiunto diverse caratteristiche di sicurezza sulla rete dei client per prevenire l'accesso non autorizzato come super utente, lo sniffing di password e altri trucchi che possono essere utilizzati su una rete locale. Una misura di sicurezza è il login sicuro tramite SSH, che è predefinito con LDM. Questo può rallentare alcune macchine client, di età superiore a quindici anni, con processore a 160 MHz e 32 MB di RAM. Anche se non consigliato, è possibile aggiungere questa linea a /opt/ltsp/amd64/etc/lts.conf:

LDM_DIRECTX=True

Attenzione: le protezioni indicate sopra si riferiscono all'accesso iniziale, ma tutte le attività espletate dopo in X utilizzano password in chiaro. Le password (eccetto quella iniziale) viaggeranno in chiaro nella rete, così come qualsiasi altra informazione.

Nota: dato che i thin-client vecchi di quindici anni possono avere problemi quando eseguono nuove versioni di LibreOffice e Firefox dovuti al pixmap caching, si può considerare di dotare i thin client di almeno 128 MB di RAM, o aggiornare l'hardware con il vantaggio di poterli utilizzare come workstation senza dischi.

Per i client Windows il dominio Windows "SKOLELINUX" è disponibile per essere usato. Un servizio speciale chiamato Samba, installato sul server principale, permette ai client Windows di archiviare profili e dati degli utenti e autenticare gli utenti attraverso il login.

per collegare i client Windows al dominio sono necessari i passi descritti nell'HowTo per Samba di Debian Edu Buster.

Windows sincronizzerà il profilo degli utenti del dominio ogni volta che si fa login e logout. Dalla quantità dei dati presenti nel profilo dipenderà il tempo di collegamento. Per minimizzare il tempo, occorre disattivare alcune cose come la cache locale dei browser (si può usare invece la cache del proxy Squid installato sul server principale) e salvare i file nel volume H: invece che in "My Documents".

Xrdp uses the Remote Desktop Protocol to present a graphical login to a remote client. Microsoft Windows users can connect to the LTSP server running xrdp without installing additional software - they simply start a Remote Desktop Connection on their Windows machine and connect.

Inoltre, xrdp può connettersi a un server VNC o a un altro server RDP.

Xrdp viene fornito senza supporto audio; per compilare i moduli necessari si potrebbe utilizzare questo script.

 #!/bin/bash
 # Script to compile / recompile xrdp PulseAudio modules.
 # The caller needs to be root or a member of the sudo group.
 # Also, /etc/apt/sources.list must contain a valid deb-src line.
 set -e
  if [[ $UID -ne 0 ]] ; then  
     if ! groups | egrep -q sudo ; then
         echo "ERROR: You need to be root or a sudo group member."
         exit 1
     fi
 fi
 if ! egrep -q  ^deb-src /etc/apt/sources.list ; then
     echo "ERROR: Make sure /etc/apt/sources.list contains a deb-src line."
     exit 1
 fi
 TMP=$(mktemp -d)
 PULSE_UPSTREAM_VERSION="$(dpkg-query -W -f='${source:Upstream-Version}' pulseaudio)"
 XRDP_UPSTREAM_VERSION="$(dpkg-query -W -f='${source:Upstream-Version}' xrdp)"
 sudo apt -q update
 # Get sources and build dependencies:
 sudo apt -q install dpkg-dev
 cd $TMP
 apt -q source pulseaudio xrdp
 sudo apt -q build-dep pulseaudio xrdp
 # For pulseaudio 'configure' is all what is needed:
 cd pulseaudio-$PULSE_UPSTREAM_VERSION/
 ./configure
 # Adjust pulseaudio modules Makefile (needs absolute path)
 # and build the pulseaudio modules.
 cd $TMP/xrdp-$XRDP_UPSTREAM_VERSION/sesman/chansrv/pulse/
 sed -i 's/^PULSE/#PULSE/' Makefile
 sed -i "/#PULSE_DIR/a \
 PULSE_DIR = $TMP/pulseaudio-$PULSE_UPSTREAM_VERSION" Makefile
 make
 # Copy modules to Pulseaudio modules directory, adjust rights.
 sudo cp *.so /usr/lib/pulse-$PULSE_UPSTREAM_VERSION/modules/
 sudo chmod 644 /usr/lib/pulse-$PULSE_UPSTREAM_VERSION/modules/module-xrdp*
 # Restart xrdp, now with sound enabled.
 sudo service xrdp restart

X2Go enables you to access a graphical desktop on the LTSP server over both low bandwidth and high bandwidth connections from a PC running Linux, Windows or Mac OS X. Additional software is needed on the client side, see the x2go wiki for more information.

Please note that the killer package should best be removed on the LTSP server if X2Go is used, see 890517.

Gli account di studenti e insegnanti che sono stati configurati via Gosa² dovrebbero essere in grado di autenticarsi su \\TJENER\HOMES o \\TJENER\<nome_utente> e accedere alla propria directory home con macchine Windows non collegate al dominio Windows SKOLELINUX.

Per impostazione predefinita solo le cartelle condivise [homes] e [netlogon] sono esportate; altri esempi di condivisione per studenti e insegnanti possono essere trovati in /etc/samba/smb-debian-edu.conf sul server principale Debian Edu.

Assicurarsi che la macchina Windows abbia il nome che si desidera utilizzare nel dominio SKOLELINUX. In caso contrario, occorre prima rinominare la macchina (e quindi riavviare). Il nome host NetBIOS della macchina Windows sarà usato in seguito in GOsa² e non può essere cambiato in quella sede (senza rompere l'appartenenza al dominio di questa macchina).

Le applicazioni Java indipendenti sono supportate senza bisogno di alcun intervento dal runtime Java OpenJDK.

Se si lavora su una workstation senza dischi, non si dispone in modo predefinito di un TGT Kerberos. Per ottenerne uno, fare clic sul pulsante credenziali nella barra di sistema. Inserire la password e il ticket sarà concesso.

Le traduzioni di questo documento sono in file PO come la maggioranza dei progetti di software libero. Maggiori informazioni sul processo di traduzione possono essere trovate in usr/share/doc/debian-edu-doc/README.debian-edu-buster-manual-translations. Anche il repository Git (vedere sotto) contiene questo file. Se si desidera aiutare a tradurre questo documento dai uno sguardo per specifiche convenzioni per le lingue.

Per effettuare il commit delle traduzioni devi essere membro del progetto Salsa debian-edu.

Controllare poi i sorgenti debian-edu-doc usando l'accesso ssh: git clone git@salsa.debian.org:debian-edu/debian-edu-doc.git

Se si desidera solo tradurre, è sufficiente controllare alcuni file da Git (questo può essere fatto in forma anonima). Si prega di inviare un bug verso il pacchetto debian-edu-doc e allegare il file PO a bugreport. Vedere per maggiori informazioni su come inviare i bug.

Si può fare il checkout dei sorgenti di debian-edu-doc da anonimo con il comando seguente (occorre avere il pacchetto git installato):

Modificare poi documentation/debian-edu-buster/debian-edu-buster-manual.$CC.po (dove occorre rimpiazzare $CC con il codice della propria lingua). Ci sono molto strumenti disponibili per la traduzione, suggeriamo di usare lokalize.

In seguito occorre fare direttamente il commit in Git (se si hanno i permessi per farlo) o mandare il file attraverso una segnalazione di bug.

Per aggiornare la copia locale del repository usare il seguente comando all'interno della directory debian-edu-doc:

Leggere /usr/share/doc/debian-edu-doc/README.debian-edu-buster-manual-translations per trovare informazioni su come creare un nuovo file PO per la lingua se ancora non ne esiste uno e come aggiornare le traduzioni.

Occorre tenere presente che questo manuale è ancora in fase di sviluppo, quindi non bisogna tradurre ogni stringa che contiene "FIXME".

Informazioni di base su Salsa (l'host dove è localizzato il nostro repository Git) e Git sono disponibili su https://wiki.debian.org/Salsa.

Se non si è mai usato Git, dare uno sguardo al libro Pro Git che ha un capitolo su come registrare i cambiamenti nel repository. Se si preferisce un'interfaccia grafica per Git invece di usare la riga di comando, si può provare il pacchetto gitk.

Alcuni gruppi di traduzione hanno deciso di tradurre tramite Weblate. Vedere https://hosted.weblate.org/projects/debian-edu-documentation/debian-edu-buster/ per maggiori informazioni.

Riportare qualsiasi tipo di problema.

Maggiori informazioni sulle (pre)release ancora più vecchie sono disponibili a http://developer.skolelinux.no/info/cdbygging/news.html.